In FRRouting 8.4 and later, bgpd frees the same memory twice when dynamic BGP neighbors disconnect, if the peer-group used by a "bgp listen range" also has a Site-of-Origin configured ("neighbor PG soo"). Each dynamic neighbor shares the peer-group's SoO value instead of getting its own copy, but frees it as its own when the neighbor is deleted, which happens as soon as its connection closes. The first disconnect leaves the peer-group pointing at freed memory, and the second disconnect frees it again, causing bgpd to abort and drop all BGP sessions on the router. Any host whose address falls inside the listen range can trigger this by opening and closing two TCP connections to the BGP port, without sending any BGP message and without knowing the AS number, and can repeat it each time bgpd restarts. If the peer-group has a TCP-MD5 password, only hosts that know the password can trigger it. Two ordinary flaps of legitimate dynamic neighbors have the same effect. Between the two frees, displaying the configuration ("show running-config") or establishing a dynamic neighbor also reads the freed memory, which can crash bgpd after a single disconnect. Only configurations that combine a listen range with a SoO on the same peer-group are affected.
In FRRouting 10.1 and later, bgpd does not correctly close a BGP session when the Send Hold Timer (RFC 9687) expires, i.e. when a neighbor has stopped accepting data from the router for twice the hold time. The connection is closed, but bgpd still considers the session to be up.
A BGP neighbor that keeps sending KEEPALIVEs but stops reading from its connection, at a time when the router has a large amount of data to send to it (for example while sending it a full routing table), can cause one of the following:
If the neighbor announced Graceful Restart support: bgpd crashes shortly after the session is closed (after the neighbor's announced restart time plus one keepalive interval), taking down all BGP sessions on the router. The neighbor can repeat this each time bgpd restarts. Otherwise: the session stays stuck in the Established state. The neighbor's routes stay installed and keep being advertised to other peers, and the neighbor cannot reconnect until an operator runs "clear bgp <neighbor>".
The neighbor does not need to be malicious; an overloaded or stuck peer can trigger the same behavior.
Required configuration: no special configuration is needed. Any BGP neighbor with an established session can trigger the issue under default settings, for example:
router bgp 65001 neighbor 192.0.2.2 remote-as 65002
Graceful Restart helper mode, which leads to the crash, is enabled by default. With default timers (keepalive 60s, hold time 180s), the session is closed about 6 minutes after the neighbor stops reading.
An integer underflow in FRRouting (FRR) stable/10.0 to stable/10.6 allows attackers to cause a Denial of Service (DoS) via supplying a crafted BGP UPDATE message.
Missing input validation in the MPREACHNLRI component of FRRouting (FRR) stable/10.0 to stable/10.6 allows authenticated attackers to cause a Denial of Service (DoS) via supplying a crafted UPDATE message.
An off-by-one out-of-bounds write vulnerability in the bgpflowspecopdecode() function (bgpd/bgpflowspecutil.c) of FRRouting (FRR) stable/10.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted FlowSpec component.
FRRouting < 10.5.3 Integer Overflow in OSPF TLV Parser Functions
A vulnerability has been found in FRRouting FRR up to 10.5.1. This affects the function processtype2route of the file bgpd/bgpevpn.c of the component EVPN Type-2 Route Handler. The manipulation leads to improper access controls. The attack can be initiated remotely. The attack is considered to have high complexity. The exploitability is reported as difficult. The identifier of the patch is 7676cad65114aa23adde583d91d9d29e2debd045. To fix this issue, it is recommended to deploy a patch.
FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the showvtyextprefprefsid function at ospfext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted LSA Update packet.
FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the showvtyunknowntlv function at ospfext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet.
FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the showvtyextprefprefsid function at ospfext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet.
FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the showvtyextlinklanadjsid function at ospfext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet.
FRRouting/frr from v2.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the opaqueinfodetail function at ospfopaque.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted LS Update packet.
FRRouting/frr from v2.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the ospfopaquelsadump function at ospfopaque.c. This vulnerability allows attackers to cause a Denial of Service (DoS) under specific malformed LSA conditions.
FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the showvtylinkinfo function at ospfext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet.
FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the showvtyextlinkrmtitfaddr function at ospfext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet.
FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the showvtyextlinkadjsid function at ospfext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet.
An issue was discovered in FRRouting (FRR) through 10.1. bgpattrencap in bgpd/bgpattr.c does not check the actual remaining stream length before taking the TLV value.
In FRRouting (FRR) through 9.1 it is possible for the getedge() function in ospfte.c in the OSPF daemon to return a NULL pointer. In cases where calling functions do not handle the returned NULL value the OSPF daemon crashes leading to denial of service.
In FRRouting (FRR) through 9.1, an infinite loop can occur when receiving a MP/GR capability as a dynamic capability because malformed data results in a pointer not advancing.
In the Opaque LSA Extended Link parser in FRRouting (FRR) through 9.1 there can be a buffer overflow and daemon crash in ospfteparseextlink for OSPF LSA packets during an attempt to read Segment Routing Adjacency SID subTLVs (lengths are not validated).
In FRRouting (FRR) through 9.1, an attacker using a malformed Prefix SID attribute in a BGP UPDATE packet can cause the bgpd daemon to crash.
In FRRouting (FRR) through 9.1 there can be a buffer overflow and daemon crash in ospfteparseri for OSPF LSA packets during an attempt to read Segment Routing subTLVs (their size is not validated).
ospfteparsete in ospfd/ospfte.c in FRRouting (FRR) through 9.1 allows remote attackers to cause a denial of service (ospfd daemon crash) via a malformed OSPF LSA packet, because of an attempted access to a missing attribute field.
bgpd/bgpflowspec.c in FRRouting (FRR) before 8.4.3 mishandles an nlri length of zero, aka a "flowspec overflow."
bgpd/bgplabel.c in FRRouting (FRR) before 8.5 attempts to read beyond the end of the stream during labeled unicast parsing.
An issue was discovered in FRRouting FRR through 9.0.1. A crash can occur when processing a crafted BGP UPDATE message with a MPUNREACHNLRI attribute and additional NLRI data (that lacks mandatory path attributes).
An issue was discovered in FRRouting FRR through 9.0.1. A crash can occur when a malformed BGP UPDATE message with an EOR is processed, because the presence of EOR does not lead to a treat-as-withdraw outcome.
An issue was discovered in FRRouting FRR through 9.0.1. It mishandles malformed MPREACHNLRI data leading to a crash.
An issue was discovered in FRRouting FRR through 9.0.1. A crash can occur for a crafted BGP UPDATE message without mandatory attributes e.g. one with only an unknown transit attribute.
An issue was discovered in FRRouting FRR through 9.0. bgpnlriparseflowspec in bgpd/bgpflowspec.c processes malformed requests with no attributes, leading to a NULL pointer dereference.