# FRRouting on RHEL 10: two denial-of-service flaws in bgpd (RHSA-2026:24347) - **Published on:** 2026-06-08 - **Category:** Security - **Original page:** https://linuxgratis.com/en/articles/rhsa-2026-24347-frrouting-flowspec-bgp-update-dos-rhel Red Hat patches CVE-2026-37457 and CVE-2026-37459 in FRRouting: two ways to crash the bgpd daemon with a crafted BGP UPDATE. Update to FRR 10.4.4 on RHEL 10. --- 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](/en/rhel) machines, also check the FRR versions inside any appliance or derived image you run in production. ## Source - Red Hat – RHSA-2026:24347: - NVD – CVE-2026-37459: - NVD – CVE-2026-37457: