CVE-2026-120221: frr: bgpd double free of peer-group Site-of-Origin when dynamic neighbors disconnect
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.
Affected Software
Event History
Frequently Asked Questions
Which configurations are affected?
Affected configurations combine a bgp listen range for dynamic neighbors with a peer-group that has a Site-of-Origin configured using "neighbor PG soo". FRRouting 8.4 and later are affected under those conditions.
What does an attacker need to trigger the failure?
An attacker only needs an address within the configured listen range and must open and close two TCP connections to the BGP port. No BGP messages or knowledge of the AS number are required; if TCP-MD5 is configured on the peer-group, the attacker must know the MD5 password.
What is the operational impact?
The second dynamic-neighbor disconnect causes bgpd to abort and drops all BGP sessions on the router. Legitimate dynamic neighbors can also trigger the issue through two ordinary connection flaps.
Can the issue cause a failure after only one disconnect?
Yes. After the first disconnect, the peer-group retains a pointer to freed memory; displaying the running configuration or establishing another dynamic neighbor can read that memory and crash bgpd.
What can be done if patching is not immediately possible?
Avoid the affected configuration combination by removing the Site-of-Origin setting from peer-groups used by bgp listen range, or avoid using that listen range with the peer-group. Restricting access to the BGP port and using TCP-MD5 limits unauthenticated triggering, but legitimate dynamic-neighbor flaps can still cause the failure.