← Back to articles
Security· 3 min read

FRRouting on RHEL 10: two denial-of-service flaws in bgpd (RHSA-2026:24347)

Red Hat published advisory RHSA-2026:24347 on 8 June 2026, fixing two denial-of-service vulnerabilities in FRRouting (the frr package) on Red Hat Enterprise Linux 10. Both share the same symptom: they crash the bgpd daemon. When that process dies, every route learned through BGP is withdrawn from the kernel forwarding table, and traffic that depended on those routes loses its path. On a transit router or a data center interconnect, that kind of crash doesn’t stay local. It cascades.

FRRouting is the routing suite many people run on RHEL to speak BGP, OSPF, IS-IS or RIP. Both bugs here live in the BGP code, and both fire while processing a BGP UPDATE message received from a peer.

CVE-2026-37457: off-by-one in the FlowSpec parser

The first one sits in bgp_flowspec_op_decode(), inside bgpd/bgp_flowspec_util.c. The component type field of a FlowSpec sub-TLV feeds a boundary check that is off by one. With a deliberately chosen value, the parser writes one byte past an allocated heap buffer. It’s a single-byte out-of-bounds write, enough to corrupt memory and bring bgpd down.

To exploit it, an attacker needs to send BGP UPDATE messages to the vulnerable FRR speaker, which means having (or spoofing) a BGP session with it. That’s not trivial from the outside if your BGP is well filtered, but among operators and in networks with many peers the trust model is broader than it looks.

CVE-2026-37459: underflow while processing an NHC TLV

The second is an integer underflow. It affects the FRR stable branches from 10.0 through 10.6. The daemon processes a BGP UPDATE with a malformed Next Hop Capability (NHC) type-length-value field. When tlv_length is crafted to land just below the remaining buffer length, the subtraction length -= tlv_length + BGP_NHC_TLV_MIN_LEN underflows into a large unsigned value. From there the parser reads where it shouldn’t and the process crashes.

The vector is again a crafted BGP UPDATE. Same result: bgpd goes down and the routes disappear.

Who’s affected and how serious it is

Red Hat rates the advisory as Important. There’s no code execution at stake according to the published analysis, only denial of service, but in network infrastructure that’s already serious. The real impact depends on your topology: if bgpd is the piece holding up your forwarding table, losing it isolates the box until the daemon restarts and reconverges.

It affects FRRouting installs on RHEL 10. Other distributions shipped their own advisories for the same CVEs (Ubuntu in USN-8376-1, for example), so check the update channel that matches your distro.

Mitigation

The fix landed in FRR 10.4.4. On RHEL 10 the updated package is frr-10.4.4-1.el10_2:

sudo dnf update frr
sudo systemctl restart frr

Restarting frr triggers a reconvergence of the BGP sessions, so plan for it or use graceful restart if you have it configured. As extra hardening, be strict about who you peer with and apply tight prefix and peer filters. The less arbitrary the set of parties who can send you an UPDATE, the smaller the surface for both bugs.

If you manage Red Hat Enterprise Linux machines, also check the FRR versions inside any appliance or derived image you run in production.

Source

Related systems

Red Hat Enterprise Linux