CVE-2026-129456 in FRRouting
Summary
by MITRE • 11/14/2026
In FRRouting, bgpd accepts a Tunnel Encapsulation attribute (type 23) whose outer TLV length does not match the length of the attribute: the mismatch is only logged and the attribute is processed anyway. A BGP neighbor can send UPDATE messages carrying such an attribute that put the reference count of the attribute's interned sub-TLV chain out of balance, so that the chain is freed while routes stored by bgpd (Adj-RIB-In entries and RIB paths) still point to it. When those routes are later replaced, withdrawn or cleared, for example when the session goes down, bgpd reads the freed memory, decrements a reference count inside it and frees it a second time. In the reporter's build without AddressSanitizer this ended in an assertion failure in bgpd's memory accounting, aborting bgpd and dropping all BGP sessions on the router, and the neighbor can repeat it each time bgpd restarts. Because freed heap memory is written to and freed again, consequences beyond a crash cannot be ruled out. An established BGP session is required. bgpd processes attribute 23 from every neighbor, including eBGP neighbors, unless it is explicitly discarded, although RFC 9012 requires it to be filtered on eBGP sessions by default. The issue was reproduced with "soft-reconfiguration inbound" configured for the neighbor, and the reporter observed that the crash does not occur on every attempt.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/14/2026
The vulnerability in FRRouting's BGP daemon represents a critical memory safety flaw rooted in improper validation of Border Gateway Protocol attributes, specifically affecting Tunnel Encapsulation attribute type 23 as defined by RFC 9012. The core technical deficiency lies in the handling of Type-Length-Value structures within this attribute where an outer TLV length mismatch with the actual attribute data is not treated as a fatal error but merely logged while processing continues. This lax validation allows malformed UPDATE messages from BGP neighbors to introduce corrupted internal state into the routing process. When such attributes are processed, they trigger a reference counting mechanism for interned sub-TLV chains that becomes desynchronized due to the structural inconsistency of the input data. The system fails to correctly account for memory allocation and deallocation cycles associated with these malformed structures, leading directly to use-after-free conditions where previously freed heap memory remains referenced by active routing tables.
The operational impact of this flaw is severe, manifesting primarily as a denial-of-service condition through process termination. When routes dependent on the corrupted attribute chain are subsequently replaced, withdrawn, or cleared during session teardowns such as neighbor resets, the BGP daemon attempts to access and decrement reference counts within memory that has already been freed by the system allocator. This action triggers an assertion failure in bgpd's internal memory accounting subsystem, causing the process to abort immediately. The consequence is a complete loss of all BGP sessions on the affected router, resulting in significant network disruption as routing convergence must be re-established from scratch. Because the vulnerability relies on specific conditions such as soft-reconfiguration inbound being enabled and may not trigger on every single attempt due to heap allocation variability, it presents a challenging but reliable vector for attackers who can maintain an established BGP session with the target device.
From a threat modeling perspective, this vulnerability aligns closely with CWE-416 Use After Free, as the application accesses memory after it has been returned to the system free pool, and CWE-20 Improper Input Validation regarding the failure to reject malformed protocol data structures. The attack vector is classified under MITRE ATT&CK technique T1498 Network Denial of Service, specifically leveraging resource exhaustion or service disruption through exploitation of software vulnerabilities rather than simple traffic flooding. Although RFC 9012 mandates that Tunnel Encapsulation attributes should be filtered on eBGP sessions by default, the implementation processes these attributes from all neighbors unless explicitly discarded, expanding the attack surface to include external peers who may not have strict filtering policies applied. This design oversight allows remote adversaries with valid BGP peering relationships to trigger the crash repeatedly upon each daemon restart, creating a persistent availability risk for critical routing infrastructure.
Mitigation strategies must address both immediate operational controls and long-term code remediation. Administrators should immediately enforce strict filtering of Tunnel Encapsulation attributes on all eBGP sessions in accordance with RFC 9012 recommendations to prevent the ingestion of potentially malicious or malformed data from external peers. For iBGP scenarios where such attributes are necessary, implementing rigorous input validation at the protocol parsing layer is essential; developers must ensure that TLV length mismatches result in immediate session termination rather than continued processing with corrupted state. Upgrading to patched versions of FRRouting that correct the reference counting logic and enforce strict attribute integrity checks will resolve the underlying memory management errors. Additionally, enabling AddressSanitizer during development builds can help detect similar heap corruption issues before they reach production environments, ensuring that future updates maintain robustness against malformed protocol messages.