CVE-2025-61100: FRRouting OSPF Opaque LSA Dump NULL Pointer DoS

FRRouting has a newly documented vulnerability — tracked as CVE-2025-61100 — that allows specially crafted OSPF Link State Advertisements (LSAs) to trigger a NULL pointer dereference in the OSPF daemon (ospfd), causing a denial-of-service (DoS) condition for affected FRR installations. The fault is rooted in the Opaque LSA dumping logic (function ospf_opaque_lsa_dump in ospf_opaque.c) and is reachable under a specific runtime condition: when OSPF packet debugging is configured to dump full send/receive details. Public vulnerability databases and the upstream FRRouting repository record the problem, a targeted patch, and guidance for mitigation.

---

Background​

What is FRRouting and why OSPF matters​

FRRouting (FRR) is an open-source routing protocol suite used widely in routers, virtual routers, network appliances, and cloud networking stacks. FRR implements multiple routing protocols; one of them, OSPF (Open Shortest Path First), exchanges LSAs describing network topology. Opaque LSAs are an OSPF mechanism for carrying protocol-specific or extension data; their parsing and diagnostic dumping code runs in the OSPF daemon (ospfd) and is accessible during routine operations and administrative debugging.

The vulnerable code path​

The vulnerability exists in the function responsible for producing human-readable dumps of Opaque LSA information. When administrators enable detailed packet dumps using the OSPF debug command (for example: debug ospf packet all send/recv detail), incoming or outgoing OSPF packets are inspected and their opaque LSA contents may be passed to the dumper routine. If a malformed LSA triggers a path where the code attempts to dereference a pointer that can be NULL (for example, due to missing VTY context or missing show_opaque_info handlers), ospfd can crash. The upstream pull request and issue describing the fix explain that the original code failed to check for the presence of the VTY context and related function pointers before dereferencing them, leading to the fault.

---

Technical analysis​

How the crash is triggered​

• The dumper routine (called during debug-mode packet processing) attempts to present opaque LSA details either to the VTY session (interactive CLI) or via zlog (daemon logging).
• Under normal operation the VTY context and LSA-specific show functions exist; however, in edge cases — malformed packets, unexpected message structures, or when the daemon’s internal state does not provide the CLI context — the code previously did not validate pointers before use.
• A dereference of a NULL pointer in process context typically results in ospfd aborting (segfault or assertion), which removes the routing process from service. That translates into interrupted routing, loss of adjacency handling, and in some deployments a full routing-plane outage until the daemon restarts. The patch introduces defensive checks and falls back to zlog when VTY is absent.

Scope and reachability​

• Affected FRR releases: v2.0 through v10.4.1 according to public trackers. The upstream fix was merged as a series of commits addressing null checks in the opaque LSA dumping functions.
• Exploit preconditions:
  • The attacker must be able to deliver a malformed OSPF LSA to the target ospfd instance.
  • The vulnerable LSA path is exercised only when OSPF detailed packet debugging is enabled (debug ospf packet all send/recv detail), which is not a default production setting in most installations. This limits the practical attack surface in default configurations. Several vendor and tracking pages emphasize that the debug setting is the common trigger.
• Attack vector: Network (crafted OSPF LS Update packets) when ospfd processes the Opaque LSA and attempts to perform the dump. Some trackers list the vector as network, while other analyses classify the vector as conditional (only when debug mode is on). Administrators must therefore consider actual running configuration when assessing risk.

---

Severity, CVSS and real-world risk​

Public scoring and vendor assessments​

• NVD and multiple aggregators list CVE-2025-61100 and summarize the technical cause: NULL pointer dereference in ospf_opaque_lsa_dump. Public CVSS assessments vary: some sources report a CVSS v3.1 score of 7.5 (High) with an availability impact; other trackers and maintainers treat the effective severity as lower because exploitation depends on a non-default diagnostic mode.
• Ubuntu’s security tracker describes the issue and assigns priority categories for their packaged frr builds; Red Hat/other vendor trackers mapped the issue to their product lifecycle and in some cases deferred fixes pending stable backporting decisions. Administrators must consult vendor advisories for precise package mappings and status for each distribution.

Practical risk analysis​

• For default production setups where detailed OSPF packet dumping is not enabled, exploitability is low: the vulnerable code path is rarely reached and the routine in question is used primarily for diagnostics.
• For networks where operators enable verbose OSPF debugging on production routers (common during troubleshooting, or on lab/edge appliances), risk increases significantly: an attacker or misconfigured neighbor could deliver crafted LSAs to crash ospfd, resulting in routing disruption.
• In multi-tenant or carrier-grade clouds where tenants may influence routing plane inputs, the conditional attack surface can be meaningful if debug settings are inadvertently left enabled. This class of null-pointer-based DoS is a classic availability threat and is frequently exploited to create sustained or persistent outages when the daemon fails to auto-recover.

---

Patch, mitigation, and remediation​

What was changed upstream​

The upstream FRR pull request introduces explicit checks before dereferencing VTY and opaque LSA handler pointers; if VTY is not available the code falls back to logging output with zlog instead of attempting to write to a non-existent CLI context. The change is surgical and limited to the diagnostic dump logic. The PR and associated commits are publicly visible in the FRRouting repository.

Immediate mitigation options (if patching is not yet possible)​

1. Disable OSPF packet debug dumps:
   • Remove or avoid issuing debug ospf packet all send/recv detail on production devices.
   • If debugging is necessary, enable it only for the shortest possible window and on devices isolated from untrusted networks.
2. Limit OSPF adjacency exposure:
   • Restrict which neighbors can form OSPF adjacencies via filters/ACLs or interface controls. Prevent untrusted peers from sending crafted LSAs.
3. Rate-limit and monitor control-plane traffic:
   • Apply control-plane policing (CoPP) or similar protections to limit the rate of LS Update messages reaching the routing daemon.
4. Monitor for crashes and auto-restart behavior:
   • Ensure ospfd is supervised by a process manager that can restart it safely, and that restarting does not produce flapping or persistent instability in data-plane forwarding.
5. Apply temporary filters:
   • If feasible, filter or drop Opaque LSAs at the interface or adjacency level until a vendor patch is available.

Recommended remediation steps (ranked)​

1. Apply the upstream or vendor-supplied fix that contains the defensive checks (the FRR commit set addressing ospf_opaque_lsa_dump). Verify the FRR release notes or vendor package changelogs for the fixed commit IDs.
2. If running a distribution package (Ubuntu, Debian, RHEL, etc., install the vendor-published security update for frr that maps to CVE-2025-61100 and reboot/restart services per vendor guidance. Confirm the updated package contains the PR commits.
3. If compiling from source, update to a commit that includes the fix and rebuild according to your deployment pipeline; validate in a staging lab before promotion to production.
4. After patching, verify with controlled tests that malformed opaque LSAs no longer crash ospfd, and ensure monitoring is in place to detect similar faults.

---

Detection and hunting guidance​

Signs and logs to watch​

• ospfd process crashes, core dumps, or segfault messages in system logs (journalctl / syslog).
• zlog entries around OSPF packet handling and crash traces immediately after Opaque LSA receipt.
• Rapid neighbor flaps or route withdrawals that trace back to OSPF adjacency loss.
• If debug mode was active, look for log lines indicating a dump attempt immediately preceding the crash.

Practical commands and checks​

• Verify FRR/ospfd version: check the installed frr package or the ospfd binary version tag.
• Search running configuration for debug directives:
  • show running-config | include debug ospf (or equivalent CLI/management interface).
• Monitor service state:
  • On systemd-managed hosts: sudo systemctl status frr and sudo journalctl -u frr -n 200.
  • Capture dmesg and kernel logs for process-level faults: sudo dmesg -T | egrep -i 'ospf|frr|segfault|core'.
• Use packet captures to inspect suspicious LS Update messages: capture on the interface receiving OSPF updates and filter for Opaque LSAs.

Threat hunting heuristics​

• Query historical logs for times when ospfd restarted coincident with receipt of LS Update packets.
• Correlate manual debugging sessions (when admins enabled debug ospf packet all send/recv detail) with subsequent crashes; long-lived debug sessions on production gear are a high-risk misconfiguration signal.
• Where possible, keep debug sessions ephemeral and tied to a ticket or troubleshooting window, with explicit start/end audit trails.

---

Operational recommendations​

• Treat the presence of debug ospf packet all send/recv detail in production configurations as a policy violation unless justified by formal troubleshooting and time-limited exception processes.
• Harden OSPF control plane exposure with adjacency filters, authentication (e.g., MD5/HMAC for OSPF neighbors where supported), and control-plane policing.
• Implement staged deployment of FRR updates: test upstream/vendor fixes in a lab, then roll to edge appliances before core routers.
• Maintain rigorous logging and centralized collection for frr/ospfd telemetry so crashes are rapidly triaged and root cause is correlated to peer packets.

---

Critical appraisal of the fix and disclosure​

What FRRouting got right​

• The remediation is focused and minimal: adding necessary NULL checks and fallback logging preserves expected functionality while eliminating the crash vector. That is a low-risk, high-impact fix that reduces the chance of regression. The upstream pull request demonstrates an appropriate developer response and code review activity.

Remaining risks and caveats​

• The vulnerability is an availability-first defect: a NULL pointer dereference is not a memory-exploitation primitive for arbitrary code execution, but it is an immediate route to DoS. That means defenders should prioritize availability controls and process supervision.
• Some vendor trackers and distro advisories deferred fixes for specific packaged branches; operators must confirm whether their vendor/chosen distribution shipped a backport, or whether manual upgrades are needed. Ubuntu’s tracker lists affected frr package statuses for several releases; administrators should not assume a fix unless their package changelog explicitly references the upstream commits.
• The practical exposure is lower for systems that never enable verbose OSPF packet debugging; however, human error (leaving debug on after troubleshooting), automated diagnostic tooling, or vendor-managed appliances with debug enabled for telemetry could turn that conditional exposure into a real risk.

On public proof-of-concept and exploitability​

• Multiple vulnerability aggregators and feeds note that proof-of-concept exploit code surfaced in public repositories. Where a PoC exists, it typically demonstrates how to craft the malformed Opaque LSA to produce the crash. The presence of PoC increases the urgency to patch or mitigate, especially in scenarios where debug dumps are enabled. Administrators should assume that code demonstrating forced crashes will be available publicly and act accordingly. (Administrators should not run public PoC scripts on production gear; instead, recreate testbeds to validate fixes.

---

Broader context: NULL-dereference DoS in network stacks​

NULL pointer dereferences remain a common cause of availability failures in networking and kernel code because they convert a localized error into a process-level or kernel-level fault. Defensive programming techniques — explicit NULL checks, careful validation of diagnostic-only code paths, and strict separation of production and diagnostic behavior — reduce attack surface. The patterns seen in FRR are consistent with other recent fixes where a missing defensive check in a diagnostic or helper routine produced outsized availability effects. Production operators should treat debug/dump code as a special class of risk and limit its exposure accordingly.

---

Executive summary and timeline for operators​

• What happened: CVE-2025-61100 is a NULL pointer dereference in ospf_opaque_lsa_dump that can crash ospfd when detailed OSPF packet dumps are enabled and a malformed Opaque LSA is processed.
• Affected versions: FRRouting releases from v2.0 through v10.4.1 were listed as vulnerable by public trackers; the upstream PR contains the fix. Verify your specific vendor/distribution package mapping before patching.
• Immediate priorities:
  1. Audit running configurations for the debug directive debug ospf packet all send/recv detail; remove or limit it in production.
  2. Patch FRR using your vendor or upstream release that includes the PR fix; if a vendor package is not yet available, consider rebuilding from a fixed upstream commit or apply documented mitigations.
  3. Harden OSPF exposure, add monitoring, and ensure ospfd is supervised for clean restarts if needed.
• Longer-term: treat diagnostic-mode code as a high-risk surface; enforce processes that prevent leaving verbose debug enabled in production, and require change control for any diagnostic toggles that could be abused to trigger vulnerable code paths.

---

Conclusion​

CVE-2025-61100 is a clear reminder that diagnostic helpers and debug routines are not harmless: they run in privileged contexts and can become denial-of-service vectors when they fail to validate the state they assume. The FRRouting maintainers issued a targeted patch to harden Opaque LSA dumping logic; administrators should treat this as an actionable security bulletin — verify whether their frr package or appliance includes the fix, remove or lockdown OSPF debug dumps on production routers, and apply vendor-provided updates. Where immediate patching is not possible, remove the debug configuration, restrict adjacency formation to trusted peers, and enforce control-plane protections to avoid being exposed to crafted OSPF LSAs. The fix is direct and low-risk; the operational cost of postponing it is the potential loss of routing-plane availability in environments where debug dumps are enabled or where OSPF adjacency boundaries are insufficiently restricted.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center