UBUNTU-CVE-2026-120033: Medium severity ubuntu/quagga vulnerability
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 trigger this. If the neighbor announced Graceful Restart support, bgpd crashes shortly after the session is closed, taking down all BGP sessions on the router, and 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 clears the session manually. The neighbor does not need to be malicious; an overloaded or stuck peer can trigger the same behavior. No special configuration is required: any established BGP neighbor can trigger the issue, and Graceful Restart helper mode, which leads to the crash, is enabled by default.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Operational
Manually clear the BGP session to allow the neighbor to reconnect.
Event History
Frequently Asked Questions
Which deployments are exposed by default?
Any router with an established BGP neighbor is affected; no special configuration is required. Graceful Restart helper mode is enabled by default, which makes the crash outcome possible when the peer has announced Graceful Restart support.
What must a peer do to trigger the issue?
The peer must keep sending BGP KEEPALIVEs while no longer accepting data from the router, during a period when the router has substantial data to send, such as a full routing-table transfer. This can be caused by a malicious peer, but also by an overloaded or stuck neighbor.
What is the impact if the peer supports Graceful Restart?
If the peer announced Graceful Restart support, bgpd crashes shortly after the connection closes. This takes down all BGP sessions on the router, and the peer can trigger the condition again after bgpd restarts.
What happens without Graceful Restart support, and what can operators do?
The affected session remains stuck in Established state: its routes stay installed and continue to be advertised to other peers, while the neighbor cannot reconnect. An operator must manually clear the session to recover it.