CVE-2024-55553: FRRouting (FRR) DoS Vulnerability

CVE-2024-55553 Overview

CVE-2024-55553 affects FRRouting (FRR) versions from 6.0 up to 10.3, exposing routers using Resource Public Key Infrastructure (RPKI) to a denial-of-service condition. The flaw resides in how FRR handles RPKI-to-Router (RTR) protocol updates. When the total size of an update received via RTR exceeds the internal socket buffer size, defaulting to 4K on most operating systems, FRR re-validates all routes in the Routing Information Base (RIB). An attacker can trigger continuous re-validation by issuing or withdrawing large numbers of Route Origin Authorizations (ROAs), degrading route handling performance across FRR instances globally and amplifying Border Monitoring Protocol (BMP) traffic to ingestors.

Critical Impact
Continuous RIB re-validation can stall route processing on FRR routers with large full tables for more than 30 minutes, disrupting BGP convergence and BMP telemetry pipelines.

Affected Products

FRRouting (FRR) versions 6.0 through 10.0.2
FRRouting (FRR) versions 10.1.0 through 10.1.1
FRRouting (FRR) versions 10.2.0 (fixed in 10.2.1)

Discovery Timeline

2025-01-06 - CVE-2024-55553 published to the National Vulnerability Database
2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-55553

Vulnerability Analysis

The vulnerability is categorized under [CWE-404] Improper Resource Shutdown or Release. FRR consumes RTR updates from RPKI cache servers through an internal socket. When the cumulative size of pending updates exceeds the socket buffer, FRR falls back to a full RIB re-validation rather than processing the updates incrementally. Routers carrying full Internet routing tables can spend more than 30 minutes completing a single re-validation pass. Repeated triggers stack this workload, sustaining elevated CPU consumption and delaying legitimate routing decisions. The effect also propagates downstream: BMP collectors receive bursts of route status changes generated by the re-validation cycle.

Root Cause

The root cause is the lack of bounded, incremental processing for RTR update streams that exceed the default socket buffer size. FRR's RPKI integration treats buffer overrun as a signal to discard staged state and reprocess the entire RIB against the current ROA set. Because the typical RTR update interval is 30 minutes, a single oversized update or a steady stream of ROA churn keeps the router in a perpetual re-validation loop.

Attack Vector

An unauthenticated network-based attacker who can influence ROA publication, or who controls an upstream RPKI cache, can craft update bursts large enough to surpass the 4K socket buffer. Continuously issuing and withdrawing ROAs forces every FRR instance peered with the affected cache to re-validate. The attack does not require credentials or user interaction and produces a sustained availability impact.

No public proof-of-concept code has been released. See the FRRouting CVE-2024-55553 Advisory and the upstream GitHub Pull Request Commit for the corrective code path.

Detection Methods for CVE-2024-55553

Indicators of Compromise

Sustained high CPU utilization on the bgpd and rpki daemons coinciding with RTR session activity.
Repeated RIB re-validation log entries in FRR logs outside the normal 30-minute update interval.
Unusual spikes in BMP route monitoring traffic exported to upstream collectors.
Elevated ROA issuance and withdrawal volume from a single upstream RPKI cache.

Detection Strategies

Baseline RTR update rates from each configured RPKI cache and alert on deviations beyond historical norms.
Monitor FRR daemon CPU and memory metrics through SNMP or node exporters, flagging sustained saturation.
Correlate BGP route churn statistics with RPKI validation cycles to identify forced re-validation loops.

Monitoring Recommendations

Ingest FRR syslog output into a centralized logging platform and build alerts for repeated revalidate events.
Track BMP collector ingestion rates and trigger anomaly detection on traffic volume from FRR speakers.
Audit RPKI cache provenance and validate that only trusted caches are configured in rpki cache statements.

How to Mitigate CVE-2024-55553

Immediate Actions Required

Upgrade FRRouting to a fixed release: 10.0.3, 10.1.2, 10.2.1, or 10.3 and later.
Restrict RTR sessions to trusted RPKI cache servers under administrative control.
Review BMP collector capacity to absorb transient bursts during the upgrade window.

Patch Information

The FRRouting project addressed the issue in versions 10.0.3, 10.1.2, 10.2.1, and 10.3. Debian users should apply updates announced in the Debian LTS Announcement. The fix is implemented in the GitHub Pull Request Commit referenced in the advisory.

Workarounds

Increase the operating system socket buffer size for the RTR socket to reduce the likelihood of buffer-driven re-validation.
Limit the number of configured RPKI caches and prefer caches that throttle ROA churn.
Temporarily disable RPKI validation on critical routers if patching cannot be performed immediately, accepting the trade-off in origin validation coverage.

bash

# Verify FRR version and upgrade on Debian-based systems
vtysh -c 'show version'
apt-get update && apt-get install --only-upgrade frr frr-pythontools
systemctl restart frr