FRRouting OSPF CVE-2025-61105 Remote DoS Crash via Debug Dump

FRRouting’s OSPF implementation contains a remotely triggerable NULL-pointer dereference in the show_vty_link_info path of ospf_ext.c that can crash the ospfd process and produce a network-impacting Denial of Service (DoS) when a specially crafted OSPF packet is processed—an issue tracked as CVE-2025-61105 and disclosed in late October 2025. (github.com)

Background / Overview​

FRRouting (commonly FRR or frr) is an open-source routing suite used widely in cloud, carrier, ISP and appliance environments to implement protocols such as OSPF, BGP and IS‑IS. Its modular daemons (ospfd, bgpd, zebra, etc.) are often run inside virtual routers, Linux-based network appliances, and containerized network functions where stability and availability are critical.
In October 2025 researchers reported a cluster of NULL‑pointer dereference issues affecting different OSPF dump and show routines. CVE-2025-61105 is one of those findings: the vulnerable code path is reachable when FRR’s OSPF packet debugging is configured to dump detailed information (the operational command is debug ospf packet all send/recv detail). Under that condition, ospfd will attempt to render packet fields via VTY-based show/dump helper functions; a missing NULL check lets crafted OSPF content cause a dereference and crash.
The National Vulnerability Database (NVD) records the vulnerability as affecting FRRouting/frr from v4.0 through v10.4.1, and the issue received a CVSS v3.1 base score in the High range (7.5) for its availability impact.

---

The technical story: how the crash happens​

Where the code fails​

When ospfd is configured to emit extremely fine‑grained packet dumps, its code paths call functions that print or serialize internal LSA details to a VTY (virtual terminal) context or to the daemon’s logs. The vulnerable function chain reaches into OSPF “opaque LSA” handling and the VTY-oriented show helpers (for example, functions in ospf_ext.c and ospf_opaque.c). One of these helpers — the show_vty_link_info / related show routines — did not verify that the VTY context or certain opaque‑LSA substructures were non‑NULL before dereferencing them. A malformed or specially crafted LS Update containing opaque LSA elements can trigger that bad path and produce a NULL dereference. (github.com)

Exploitation prerequisites and reachability​

This is an important nuance: the vulnerable show/dump paths are not exercised during normal forwarding or routine OSPF operation. They are invoked only when packet debug/dump is enabled (the “debug ospf packet all send/recv detail” command). That makes exploitation conditional: an attacker must be able to deliver a crafted OSPF packet to an instance where detailed OSPF packet debugging is active. In many deployments that debug configuration is not present in production, but operators sometimes enable it temporarily for troubleshooting, or forget to disable it afterward—creating a window of exposure. Multiple security trackers note the debug-dependent exposure and treat the issue as high-impact but somewhat constrained by that runtime condition.

What the impact looks like in practice​

A successful exploit causes the ospfd process to crash. For single-node or non-redundant routers this can mean an immediate loss of OSPF adjacency and route advertisements, creating total loss of availability for affected routing domains. In clustered or redundant topologies, the outage may be contained or transient, but operators report real operational pain when routing daemons crash—route flaps, reconvergence storms, and downstream application outages can follow. Because the failure is a straightforward crash (NULL dereference), the flaw does not appear to provide memory‑corruption primitives for remote code execution; its primary impact is availability.

---

Timeline and remediation status​

• Discovery and public disclosure: the issue was publicly disclosed and tracked in late October 2025, with corresponding GitHub issue and pull request activity starting in August 2025 and disclosure consolidated at the end of October. (github.com)
• Upstream patch activity: a focused pull request (PR #19480) was submitted to add NULL‑checks and fallback behavior (log via zlog when vty is unavailable) and to harden the opaque‑LSA dump code. That PR was discussed, reviewed and merged to the project’s master branch. (github.com)
• Releases and packaging: FRRouting’s release train shows multiple 10.x bugfix releases in early 2026 (including 10.4.2 and later tags), which collect many bugfixes across daemons; the upstream PR provides the fix, but downstream OS packages and vendor distributions vary in whether the fix has been packaged and distributed. Several distributors (Debian, Ubuntu and some vendor trackers) flagged the packages as vulnerable or set their status to “fix deferred” for particular distro branches—operators must verify per-vendor package status rather than assume immediate availability. (github.com)

Because packaging and backporting decisions differ, the pragmatic remediation path is to either upgrade to a fixed FRR upstream release (one containing the merged PR) or to apply the upstream patch in your build pipeline and rebuild vendor packages; if relying on distribution packages, confirm the fix is present in the exact package version you will deploy. Snyk and other trackers note that the upstream fix was pushed to master but not necessarily published in every distribution’s official package repositories at disclosure time.

---

Practical risk assessment — who should worry, and why​

• High-risk targets
• Edge routers and single‑node appliances running ospfd with detailed packet debugging enabled. These instances are trivial to crash remotely if an attacker can deliver crafted OSPF packets.
• Environments that accept OSPF from untrusted peers (for example multi-tenant or service provider edge networks where OSPF adjacency spans a shared boundary) because the attacker only needs network reachability to the OSPF process.
• Moderate-risk targets
• Redundant topologies and well‑architected networks: while ospfd may crash on one node, redundancy can mask the impact and allow failover. Even so, reconvergence and repeated crash cycles can cause fold‑back effects—control-plane noise, CPU spikes, and transient route instability—so these setups are not immune. (github.com)
• Low-risk scenarios
• Instances where OSPF debug is definitively disabled and the routing plane is otherwise shielded by filtering that blocks OSPF (IP proto 89) from untrusted sources. Because the exploit path is debug-dependent, removing that condition essentially eliminates the direct attack vector.

Scoring and exposure: public scoring (CVSS v3.1 = 7.5) reflects the seriousness of an unauthenticated, network‑accessible DoS that causes full availability loss for the daemon. But the real operational severity depends on whether debugging is enabled and on network topology. Trackers and distributors tend to conservatively rate the issue high because of the simplicity of triggering and the immediate operational consequences if exploited.

---

Mitigations and operational guidance​

If you operate FRR or manage OSPF‑enabled network appliances, take a prioritized, layered approach. The following recommendations are ordered from immediate short-term mitigations to longer-term remediations.

Immediate (minutes to hours)​

• If you suspect any installations have OSPF debugging enabled, disable it immediately:
• Run: no debug ospf packet all send/recv detail (or remove equivalent debug settings).
• Confirm via vtysh and daemon logs that debug is off.
• At the network perimeter and between trust zones, enforce filtering to block unauthorized OSPF packets (OSPF uses IP protocol 89). Deny OSPF from external and untrusted subnets; only allow adjacency from known, trusted peers.
• If you cannot immediately update, place ACLs or ACL‑like controls close to the ospfd hosts (host-level firewall or upstream router) to block suspicious LSAs or OSPF from unexpected sources.

These immediate steps remove or reduce the attack surface by either removing the debug invocation that exposes the code path or by preventing attackers from reaching the OSPF process. Several public advisories specifically call out disabling debug and network filtering as short‑term mitigations.

Short-to-medium (days)​

• Apply the upstream patch or upgrade to an FRR release that contains the merged fix (verify the PR/commit is present in your targeted tag). Upstream PR #19480 and its commits implement NULL checks and safer logging behavior; include that change in your build. (github.com)
• If you use distribution packages (Debian, Ubuntu, RHEL, etc.), check the distro security tracker for your release and install the vendor-supplied patched package when available; do not assume all vendors backport immediately. Debian’s tracker and Ubuntu’s security page list package status and “fix deferred” notices for some releases.
• Harden monitoring and automation:
• Add alerts for repeated ospfd crashes, restarts, or OSPF adjacency flaps.
• Instrument packet captures and flow logs for unexpected OSPF LS Update traffic from unknown sources.

Long-term (weeks to months)​

• Review operational debugging practice: implement policies that strictly control when and where debug ospf packet all send/recv detail may be enabled. Use ephemeral debug sessions with automatic timeouts or require just-in-time authorization.
• Adopt compartmentalization: limit control-plane exposure by isolating routing protocol control traffic into management VRFs or out-of-band management networks.
• Integrate FRR security patching into your CI/CD and image‑build pipelines so upstream fixes are incorporated quickly and consistently across appliances and container images.
• For vendors: treat temporary packet‑dump helpers as potential attack surfaces—consider adding safe, defensive guards (null checks, fallback paths) to all code that formats or prints externally controlled protocol content.

---

How to verify whether you're fixed​

• Check the upstream repository for the merged commit(s) referenced in PR #19480 and confirm that the fix commit appears in your deployed tag. The FRRouting PR and commit history show the targeted changes; operators rebuilding from source can apply or cherry‑pick the exact commit. (github.com)
• If you rely on vendor packages, consult your OS vendor’s security advisory pages (Debian, Ubuntu trackers) and your vendor’s changelog for the frr package version that includes the fix. Do not assume a system update will carry the fix unless the vendor marks the package as updated.
• Functional verification:
• Ensure debug ospf packet all send/recv detail is disabled and verify no crash occurs when processing expected OSPF packets.
• In a controlled lab, apply a crafted LS Update test case (preferably using the public PoC or a trusted test vector) to confirm the patched daemon no longer crashes. Note: execute tests in an isolated lab environment only.
• Confirm that when vty is unavailable the daemon falls back to logging (zlog) rather than dereferencing NULL—this is the behaviour intrm(ospfd: Fix NULL Pointer Deference when dumping opaque lsa by s1awwhy · Pull Request #19480 · FRRouting/frr))

If you cannot safely perform active tests, rely on code presence (commit/patch) checks and vendor package version mappings as your assertion of remediation.

---

What went right — and where the risks remain​

Strengths and positive signals​

• Upstream responsiveness: The FRR community received the report, and a targeted PR was produced to add defensive checks to the dump helpers and to ensure safer fallback logging behavior. That patch was discussed and merged into master, which is a good example of quick upstream remediation for a clear coding oversight. (github.com)
• Clear scope reduces blast radius: Because the code path is only invoked when detailed packet dumps are enabled, the default exposure in well-managed production networks is significantly lower than a completely unauthenticated, always-reachable crash path. Vulnerability trackers and distro advisories consistently note this limiting factor.

Risks and weaknesses​

• Operational misconfigurations: Operators commonly enable verbose debugging during troubleshooting and sometimes forget to disable it, especially in ephemeral cloud or virtualized environments. That human factor preserves an easy attack vector. Community threads and multiple CVE entries in the same family show this pattern repeatedly.
• Distribution lag and deferred fixes: Several mainstream distributions flagged these packages as vulnerable with fixes deferred or pending. Enterprises that depend on vendor packaging cannot assume a safe state until the distro packages are updated and validated. That means operators must either rebuild upstream or implement mitigations until vendor packages are available.
• Protocol diagnostic surface area: Any code that attempts to pretty‑print complex protocol payloads (opaque LSAs, extended TLVs, etc.) increases attack surface; the community should treat “diagnostic dump” code with the same rigor as parsing code that handles production packets. The PR fixes the immediate NULL check flaws, but the broader class of debug/dump errors remains a recurring maintenance concern. (github.com)

---

Incident response playbook (concise checklist)​

• Stop the bleeding
• Immediately disable OSPF packet debug on all production nodes.
• Block OSPF (IP proto 89) at network edges and untrusted links where possible.
• Contain
• Identify any nodes with ospfd crashes in the last 7 days; review supervision logs (systemd, respawners) and core dumps.
• Quarantine affected nodes from production routing while preserving logs for forensics.
• Patch and verify
• Apply upstream commit from PR #19480 (or upgrade to FRR upstream tag that contains the commit).
• If using distro packages, wait for vendor advisory and then patch; if vendor backports are delayed, rebuild from upstream in your controlled build pipeline.
• Verify with lab tests or commit lookup that the fix is present.
• Hardening and lessons learned
• Implement strict debug usage policies and automation that disables debug after a short interval.
• Add detection rules that alert on unexpected OSPF LS Update payloads or unusual OSPF source addresses.
• Review other diagnostic printing paths in the code base and add defensive null checks and safe fallback logging.

---

Broader context and takeaways​

CVE-2025-61105 is symptomatic of a recurring class of vulnerabilities: code that is intended for human-friendly diagnostics ends up traversing paths not exercised during normal operation and is insufficiently guarded against missing contexts (like a missing VTY pointer). The vulnerability’s exploitability is straightforward when the debug context exists, and the operational consequences—route loss, reconvergence and application outages—are real.
The good news is that the upstream change is small and focused: add defensive checks, and log via safe channels when the interactive context is missing. The harder problems are operational: ensuring that debug features are tightly controlled, that image and package build pipelines can ingest upstream fixes quickly, and that distributors publish timely backports for their supported releases.
Network operators should treat control-plane diagnostics and their interfaces as first‑class security concerns: they run with privileged context, they process untrusted wire data, and they can directly affect availability. The immediate action is simple: confirm debug is off, apply the upstream fix where possible, and harden network boundaries. Beyond that, teams should audit other "dump" helpers across protocol implementations and add automated tests that exercise debug paths under defensive conditions so a missing NULL check cannot cause a production outage again. (github.com)

---

Conclusion​

CVE-2025-61105 is a reliable, remote denial-of-service vector against FRRouting’s OSPF daemon when detailed packet debugging is enabled. The technical fix is straightforward and upstreamed, but operational realities—debug enabled in the wild and variable vendor packaging timelines—mean the vulnerability remained relevant to many deployments after disclosure. Operators must act on multiple fronts: disable unnecessary OSPF debug, enforce network filtering for OSPF traffic, verify vendor package status, or rebuild with the upstream fix, and finally, institutionalize safer debug practices so that diagnostic helpers do not become accidental attack surfaces in the future.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center