Ubuntu Fixes FRR Routing Regression That Quietly Broke RPKI Revalidation
Canonical has issued USN-7230-3 to correct a regression that its own earlier security update introduced into the FRRouting suite of internet protocols. The earlier notice, USN-7230-2, fixed two denial-of-service flaws in FRR, but the patch applied for CVE-2024-55553 broke RPKI support in the process. Affected systems span Ubuntu 24.04 LTS, 22.04 LTS and 20.04 LTS, covering the frr and frr-rpki-rtrlib packages. Any operator running FRR as a BGP speaker with the RPKI module enabled on those releases was exposed to the faulty behaviour rather than to a new attacker-facing bug. Because this is a defect in a fix and not a newly exploitable flaw, with no exploitation reported for either underlying CVE, it sits in routine patching rather than out-of-hours incident handling — with the exception of Ubuntu 20.04 LTS hosts whose BGP daemon is already failing to start, where the impact is live and immediate.
The defect is a functional one in route validation handling. After the CVE-2024-55553 fix was applied, FRR stopped processing RPKI updates after the first one, meaning routes were no longer revalidated when the RPKI data set changed. On Ubuntu 20.04 LTS the effect was more immediate: the BGP daemon failed to start altogether when the RPKI module was enabled. The underlying issues the earlier update addressed were both availability flaws — CVE-2024-44070, reported by Iggy Frankovic, concerned incorrect handling of certain BGP messages that a remote attacker could possibly use to crash FRR, and only affected Ubuntu 20.04 LTS, while CVE-2024-55553 involved FRR re-validating all routes when the internal socket buffer size overflowed, which a remote attacker could possibly use to degrade performance. Canonical has not published exploitation details beyond those descriptions, and the regression itself is a defect in the fix rather than a separately exploitable weakness.
The practical consequence is a silent loss of assurance in a control many networks rely on. RPKI origin validation only has value if it reflects current data, so a BGP speaker that accepts one update and then ignores every subsequent change is operating on an increasingly stale view while still appearing to have validation enabled. On Ubuntu 20.04 LTS the failure is louder but more disruptive, since a BGP daemon that will not start with the RPKI module loaded forces operators into a choice between routing availability and validation. That release is also past standard support, so the corrected frr and frr-rpki-rtrlib builds at version 7.2.1-1ubuntu0.2+esm5 are delivered through Ubuntu Pro ESM Apps rather than the ordinary archive. Neither of the original CVEs shows evidence of active exploitation: FIRST EPSS places CVE-2024-55553 at a 0.8 percent probability of exploitation in the next 30 days and CVE-2024-44070 at 0.6 percent, and neither appears in any confirmed in-the-wild campaign. The realistic risk here is operational — degraded routing hygiene and, on one release, a routing daemon that does not come up — rather than an imminent attack.
Attack Surface
Infrastructure, Server OS
Tactics
Impact
Techniques
- T1498 – Network Denial of Service
- T1499 – Endpoint Denial of Service
- T1565 – Data Manipulation
SuperPRO's Threat Countermeasures Procedures
- On Ubuntu 24.04 LTS (noble), update frr-rpki-rtrlib to 8.4.4-1.1ubuntu6.8 or later, which reverses the RPKI regression introduced by the USN-7230-2 fix for CVE-2024-55553.
- On Ubuntu 22.04 LTS (jammy), update frr-rpki-rtrlib to 8.1-1ubuntu1.17 or later via the standard archive.
- On Ubuntu 20.04 LTS (focal), update frr and frr-rpki-rtrlib to 7.2.1-1ubuntu0.2+esm5; these builds are delivered through Ubuntu Pro ESM Apps, so enable Ubuntu Pro on affected hosts with 'sudo pro attach' and 'sudo pro enable esm-apps' before attempting the upgrade.
- Restart the FRR service after upgrading ('sudo systemctl restart frr') and confirm bgpd is running on Ubuntu 20.04 hosts where the RPKI module previously prevented the BGP daemon from starting.
- Verify RPKI state is live again by checking that the cache session is established and prefixes are being revalidated, using 'vtysh -c "show rpki cache-connection"' and 'vtysh -c "show rpki prefix-table"' and comparing the entry count against the cache server's current VRP set.
- Add a monitoring check that alerts when the FRR RPKI cache-connection drops or the prefix-table entry count stops changing across successive polls, so a future stalled update stream is detected rather than silently trusted.
- Restrict TCP/179 BGP sessions and the RTR cache port to known peer and cache-server addresses at the host firewall, limiting remote reachability of the BGP message handling paths covered by CVE-2024-44070 and CVE-2024-55553.
