CVE-2025-61099: FRR OSPF Debug Dump NULL Pointer DoS

A remotely triggerable NULL pointer dereference in FRRouting’s OSPF implementation has been cataloged as CVE-2025-61099 and can crash the OSPF daemon (ospfd) when a crafted Link-State (LS) Update packet is processed while detailed OSPF packet debugging is enabled. The bug, present in upstream FRRouting/frr releases from v2.0 through v10.4.1, is caused by a missing validation in the code path that dumps Opaque LSA details; exploitation results in a Denial of Service (DoS) that can remove routing capability from affected routers and appliances until the daemon is restarted or patched.

---

Background​

What is FRRouting and why this matters​

FRRouting (FRR) is an open-source routing suite that implements major routing protocols—BGP, OSPF, IS-IS, RIP, and more—and is widely embedded in network operating systems, virtual router appliances, data-center hosts, ISPs and edge devices. Because FRR is often deployed in critical routing planes, a crash in a single routing daemon such as ospfd can lead to immediate loss of routes, traffic blackholing, or flapping routes across a network. This makes even a non-exploitable memory error operationally significant.

The OSPF component and Opaque LSAs​

Open Shortest Path First (OSPF) is a link-state routing protocol that floods LSAs to exchange topology information. One LSA class—Opaque LSAs—is used to carry extended/opaque information such as Traffic Engineering or OSPF extensions and is parsed by ospfd when received or sent. The vulnerability sits in the LSA dumping routine used when administrators enable verbose packet debugging; that diagnostic path attempts to render or log details of opaque LSAs and doesn't always check that the function pointers or VTY (virtual terminal) context exist before calling them. When a NULL pointer is dereferenced in that path, ospfd crashes.

---

What happened: technical summary​

• A NULL pointer dereference exists in the OSPF LSA-detail dumping code (the code referenced as the opaque_info_detail / show_opaque_info_detail function in ospf_opaque.c). When the daemon is instructed to display detailed packet dumps (via the debug ospf packet all send/recv detail family of commands), that code path is reachable.
• A crafted LS Update packet that triggers the opaque LSA handling logic can cause an unguarded function pointer or VTY pointer to be used, leading to a NULL dereference and a crash of ospfd. The crash causes immediate loss of OSPF routing capability on the host.
• Because OSPF is a network-layer routing protocol, the LS Update that triggers the fault can be supplied remotely from any system that can deliver OSPF packets to the vulnerable router (for example, a directly connected host, a tenant VM on the same segment, or a BGP/MPLS environment that allows OSPF adjacency formation). The attack requires no authentication if a router processes the packet, though practical exploitation depends on network topology and OSPF neighbor/authentication configuration.

These are the core, load-bearing technical claims about CVE-2025-61099 and the conditions under which it can be triggered.

---

Scope and severity​

Affected versions​

Upstream FRRouting releases from v2.0 through v10.4.1 are listed as affected; users running those versions should consider them vulnerable unless they have applied the specific upstream fix. Distribution packages may lag behind upstream fixes, so OS vendor packages (Debian/Ubuntu/RHEL derivatives) must be checked independently.

CVSS and practical impact​

NVD and multiple vulnerability trackers report a CVSS v3.x score in the High range (commonly seen as 7.5) because the attack is network-accessible, requires no privileges or user interaction, and has a direct high-impact effect on availability (complete daemon crash). The vulnerability does not appear to enable code execution, privilege escalation, or information disclosure—its impact is denial of service. Assessments from downstream trackers confirm a high availability impact but note important exploitation preconditions (notably debug mode).

Real-world exposure: when this is most dangerous​

• Production routers and appliances rarely run OSPF debug-level packet dumps continuously. In many environments the detailed packet debug ospf packet all send/recv detail is used transiently for troubleshooting. That reduces the default exposure compared to a flaw triggered in standard processing.
• However, many smaller systems, development/test clusters, or misconfigured devices may have debug logging enabled longer than intended. Cloud and multi-tenant environments where untrusted tenants share Layer 2 segments are especially risky, because an attacker on the same segment could supply crafted LS Updates.

---

How the problem was addressed (upstream and distributions)​

• An upstream pull request (PR #19480) was submitted that adds the missing NULL checks around the VTY context and the show_opaque_info function pointer, and ensures that when a VTY context is not present packet details are logged via zlog instead of invoking a NULL function pointer. The PR and associated commits provide the programmatic fix to prevent the crash path.
• Upstream release activity shows continued FRR development (e.g., the 10.5.0 release), but whether a specific distribution package includes the fix depends on their release cycles and patching status; some distributions have marked the issue as vulnerable or with fixes deferred. System administrators must verify their OS vendor package status rather than assume an automatic fix.

Caution: while the upstream PR provides a clear remediation, package-level availability and the exact release that contains the fix vary. Some downstream advisories indicate the fix was added to the upstream repository but had not yet been rolled into distribution packages at the time of their advisories. Always check the version in your distro repository or build FRR from a fixed upstream commit if necessary.

---

Exploitability — how easy is it to weaponize?​

• Attack vector: network. The attacker must be able to send OSPF LS Update packets to the target process. That usually means being on a network path where the router will accept OSPF packets or be able to craft packets that reach the OSPF processing code path.
• Attack complexity: low if the required conditions are met (debugging enabled and reachable OSPF packet ingestion). If those conditions are absent, the attack path is effectively closed. This duality is why many maintainers and security teams emphasize the non-default runtime condition—debug-level packet dumps—as a major limiter for mass exploitation.
• Privileges: none. The code path is triggered by packet handling, so an unauthenticated attacker on the relevant network can attempt exploitation.

Summary judgement: the vulnerability is easily weaponizable in networks where detailed OSPF packet debugging is enabled and unmanaged OSPF traffic is reachable. In hardened networks with strict neighbor authentication, network segmentation, and no active debug logging, practical exploitation is substantially harder.

---

Operational impact: what a successful exploit does​

A successful exploit will cause the local ospfd process to crash. The immediate consequences can include:

• Loss of all OSPF-learned routes on that host; depending on topology, this can isolate parts of the network or force traffic onto suboptimal paths.
• Routing flaps and SPF recomputation across adjacent routers, potentially causing transient network instability.
• If the affected device is a central or edge router, the result can be a sustained service outage until ospfd is restarted or the system is recovered.
• In multi-router setups, repeated or distributed exploitation can produce sustained disruptions or cascading outages during periods of high routing churn.

---

Detection and verification for operators​

Check whether you are vulnerable and whether the risky debug mode is enabled:

• Confirm the installed FRR version:
• On Linux package-based installs: dpkg -l | grep frr or rpm -qa | grep frr.
• From source or container images, verify frr --version or check the running binary metadata.
• Check whether OSPF debugging is active:
• Enter vtysh and run show debugging ospf or look for active debug commands in the running-config. FRR documents the debug ospf packet ... commands and show debugging ospf output. If debug ospf packet all send/recv detail (or a variant that includes detail) is active, the vulnerable dumping path can be invoked.
• Review logging and zlog outputs for repeated ospfd crashes or stack traces; an unexpected crash correlated with OSPF packet dumps is an indicator of exploitation or triggering of the vulnerable path.

Place these checks into regular configuration audits and monitoring; treat enabling of packet-level detail debug on production routers as an alert condition unless it is explicitly required for a time-limited troubleshooting operation.

---

Immediate mitigations (practical, low-friction steps)​

Until you have applied a patched FRR package or upstream commit, reduce exposure with these operational mitigations:

• Disable OSPF verbose packet debugging immediately on any production router: from vtysh, run the corresponding no debug ospf packet all send/recv detail (or the specific no debug ospf packet ls-update send/recv detail) command, then disable terminal monitor if used to push logs to a console. This removes the vulnerable debug-only code path.
• Network-segment and firewall controls: block or filter OSPF (protocol 89) from untrusted segments and hosts. Ensure that OSPF adjacency formation is limited to intended neighbors only. Use ACLs or filtering to prevent unauthorized hosts from injecting LS Update packets.
• OSPF authentication: apply and enforce OSPF authentication (simple password or MD5/HMAC mechanisms supported by FRR) on all neighbor relationships so that only authenticated neighbors’ LSAs are accepted. Authentication prevents many classes of unauthenticated LSA injection.
• Operational hygiene: treat debug commands as temporary. Enforce change control that ensures debug logging is disabled when troubleshooting is finished. Add configuration audits that search for active debug statements.

These mitigations are immediate and practical: turning off detailed packet dumps or restricting access to OSPF packets will substantially reduce the attack surface while a formal patch is deployed.

---

How to remediate (recommended steps)​

• Inventory: locate all FRR installations (routers, VM appliances, containers) and record FRR versions and whether ospfd is running with OSPF debug detail enabled.
• If debug is enabled anywhere in production, disable it immediately as described above. Confirm show debugging ospf returns no active detail debug commands.
• Apply the upstream fix or vendor-supplied patched packages:
• If your OS vendor has published a security update for frr, apply that package through normal patch management.
• If no vendor package is available, consider building FRR from the upstream commit that implements the patch (for disciplined teams) or upgrading to an upstream release that includes the fix once it is published by FRR. Verify the PR/commit information before building.
• After patching, restart the ospfd process in a controlled maintenance window and monitor logs for stability. Confirm the ospfd process no longer crashes when receiving crafted test LS Updates in a lab replica before re-enabling any debug-level logging.
• Harden: add OSPF neighbor authentication and network-level filtering to reduce future risk exposure. Document debug enablement procedures and impose time-limited windows for verbose troubleshooting.

---

Vendor and distribution status — what admins need to verify now​

• Upstream: a patch/PR addressing the crash was submitted to the FRRouting repository (PR #19480 and associated commits). Administrators and packagers should track whether that PR has been merged into the release branch they use or whether a release containing the fix has been published.
• Distributions: packaging and patch availability varies. Some downstream trackers and distros (for example Debian and Ubuntu advisories) have flagged the issue in their package trackers and in some cases shown the fix as deferred or unfixed pending package updates. Do not assume your distribution has deployed a fix until you confirm its package changelog or advisory explicitly mentions CVE-2025-61099.

If your environment relies on vendor appliances or embedded images (network OS vendors, virtual appliances), contact the vendor for patches or guidance: vendor-specific images may require their own updates even if upstream FRR has a fix.

---

Risk analysis and critical commentary​

Strengths in the ecosystem response

• The issue is narrowly scoped to a debug-only code path, which reduces the default exposure and means many production setups are not immediately exploitable.
• An upstream PR and concrete fixes were created quickly and published in the FRR project, showing a responsive open-source maintenance action.

Residual and ongoing risks

• Human error and operational practices: administrators often enable verbose debugging for troubleshooting and sometimes forget to turn it off—this operational practice can turn a low-exposure bug into a critical outage vector.
• Distribution lag: many environments depend on vendor-supplied packages. When distro packages lag or mark fixes as deferred, the operational window where networks are vulnerable can extend for weeks or months.
• Network proximity and multi-tenant risks: in cloud or shared-premises deployments, untrusted tenants or co-resident VMs might be able to inject OSPF packets; absent strict segmentation or authentication, the risk of remote disruption is non-trivial.
• Incomplete hardening: OSPF authentication is not always configured, and many networks accept routing protocol packets on internal segments—this default trust model is a recurring root cause of protocol-level attacks.

Operational recommendation: treat protocol debug commands as a privileged configuration item, enforce administrative controls to prevent accidental long-lived debug sessions, and integrate protocol-specific checks into configuration audits and continuous compliance tooling.

---

Quick checklist (for immediate use)​

• From vtysh, run show debugging ospf. If any detail debug is active, run no debug ospf packet all send/recv detail or the equivalent no debug ospf packet <type> ... detail.
• Confirm FRR package/version on each host; if frr <= 10.4.1, assume vulnerable until you can verify the fix in upstream or your distro package.
• Contact your OS vendor or appliance vendor for patch guidance if you use packaged distributions or appliances. Check vendor advisories for CVE-2025-61099 status.
• Enforce OSPF neighbor authentication and block unsolicited OSPF traffic from untrusted networks with firewall rules or ACLs.
• If you must run debug for troubleshooting, do so only from a secure management workstation, limit the duration, and monitor the device closely for crashes.

---

Conclusion​

CVE-2025-61099 is a reminder that diagnostic code paths are not innocent extras: when diagnostic features are left enabled in production, they can expose code that was not hardened for ordinary runtime conditions. The FRRouting community provided a code-level fix, but the real-world security outcome depends on prompt patching, disciplined debug management, and basic protocol hardening such as authentication and proper network segmentation. Operators should assume that any router running FRR versions up to 10.4.1 that also has detailed OSPF packet dumps enabled is at unacceptable risk, and should act now to disable debugging, apply vendor or upstream fixes, and harden OSPF neighbor handling.

---

Important caution: some distribution packages and appliance images may still be unpatched even though an upstream PR exists; confirm the precise package-level status for your environment before re-enabling any OSPF debug logging.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center