CVE-2025-61106: FRR OSPF NULL Pointer DoS (v4.0 to v10.4.1)

FRRouting (FRR) versions from v4.0 through v10.4.1 contain a NULL pointer dereference in the OSPF code that can be triggered by a crafted OSPF packet, allowing an attacker to crash the ospfd daemon and cause a Denial of Service (DoS) across affected deployments.

Background​

FRRouting (commonly abbreviated FRR or frr) is an open-source routing suite used widely in ISPs, cloud providers, network appliances, and carrier and enterprise networks to implement OSPF, BGP, IS-IS and other routing protocols. Its modular daemons (zebra, ospfd, bgpd, etc. run as separate processes and talk over internal APIs and VTY shells for control and diagnostics. The vulnerability tracked as CVE-2025-61106 was disclosed in late October 2025 and is cataloged by major vulnerability databases and vendor trackers. This issue is one of several NULL‑dereference and packet‑parsing robustness issues disclosed across networking stacks during 2024–2025, but it is specific to the OSPF implementation (ospfd) within FRR and to an OSPF "dump" or debug path that prints detailed packet internals. Multiple vendors and trackers have assigned a high availability impact (CVSS v3 ~7.5), because the immediate effect is process crash and routing disruption.

---

What exactly is CVE-2025-61106?​

• Vulnerable component: FRRouting / frr — ospfd (OSPF daemon).
• Affected versions: v4.0 through v10.4.1 inclusive.
• Root cause: NULL pointer dereference in a function used when dumping details of OSPF elements (the function name reported in public records is show_vty_ext_pref_pref_sid / show_vty_ext_pref_pref_sid or related show/dump helpers in ospf_ext.c/ospf_opaque.c). The dereference occurs during detailed packet or LSA dumping.
• Trigger: A specially crafted OSPF packet (in practice an Opaque LSA / specific OSPF payload) delivered to a running ospfd process can cause the crash path to execute. In public disclosures the crash is reproducible when the daemon is configured to print detailed packet dumps (for example, when the debug ospf packet all send/recv detail debug setting is enabled).
• Impact: Denial of Service (DoS) — ospfd crashes, removing OSPF routing adjacency and potentially disrupting routing in affected topologies. Availability is the primary concern; confidentiality/integrity are not reported as impacted by this flaw.

---

Technical analysis — how the bug works​

The vulnerable code path​

The vulnerability lies in the OSPF packet/LSA dumping routines. When FRR is configured to produce verbose packet dumps (a diagnostic feature used to troubleshoot routing behavior), ospfd invokes helper functions to render structured packet fields to either the VTY (interactive CLI) or to the zlog logging system. The public issue and the upstream pull request show the failure is caused by missing NULL checks around the VTY context or related pointers used during the dump routine; if the VTY pointer is NULL or a helper like show_opaque_info is unavailable, the code will attempt to dereference a NULL pointer. This class of error is a textbook CWE-476 NULL Pointer Dereference: a caller assumes the callee returned a valid pointer, but under certain inputs or runtime states the pointer is NULL and a dereference leads to a crash. In routers and routing daemons, a crash of the routing process has outsized operational impact — lost routes, adjacency resets, and potential network partitions.

Trigger conditions and realistic reachability​

• The code path is reachable when packet-dumping is enabled; many public reports and the upstream issue indicate the crash reproduces when debug ospf packet all send/recv detail is active. That limits the most trivial exploit scenarios because detailed packet dumps are usually enabled only temporarily for troubleshooting, not in high-throughput production forwarding paths.
• However, many operator environments enable debug logging during incident response or have automated diagnostics that may briefly enable verbose logging; in multi-tenant or badly controlled environments, the attack surface increases.
• An attacker needs the ability to deliver crafted OSPF packets to the target (network reachability to the OSPF adjacency or to a segment where such packets are accepted). Because OSPF is a link‑local routing protocol by design, the attacker typically must be adjacent on the network or must control a host within the OSPF domain. That said, compromised hosts or network appliances within the same broadcast domain, or misconfigured tunnels, can make remote exploitation practical. Public trackers classify the vector as network‑accessible (AV:N) and the exploit complexity as low.

Patch rationale​

Upstream fixes submitted in the FRR project add defensive checks for the VTY context and related pointers before performing show/dump operations; when the VTY is not available, the code falls back to writing packet details to the standard logger (zlog) rather than dereferencing a NULL pointer. The pull request and commits show the exact defensive approach: validate pointers and avoid assuming a VTY exists when dumping from code paths that might be invoked without interactive context.

---

Severity and real-world risk​

Multiple vulnerability trackers give this issue a High severity rating predominately because a single crafted packet can crash ospfd and thus remove a routing protocol instance from service. Typical public scoring reports a CVSS v3.1 base score of ~7.5 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Several vendor trackers (Ubuntu, SUSE, Tenable, NVD/OSV entries) echo this scoring or classify the risk as high for availability. Why availability is emphasized:

• OSPF is a distributed control plane. If an OSPF process crashes, it can take down route propagation, causing path outages or blackholes until the daemon is restarted and adjacencies reform.
• In provider and cloud networks, route instability or a single routing instance crash can cascade to many tenants or services.
• Even if the daemon auto-restarts (some deployments run watchdogs), repeated exploitation or high-frequency triggering can create sustained outages and complicate forensic efforts.

That said, context matters:

• If debugging output is never enabled on production boxes, the vulnerable code path may be rarely exercised, reducing immediate exploitability.
• If operation and management planes are strictly separated and OSPF adjacency formation is limited by physical topology and ACLs, remote exploitation becomes more difficult.

Operators must assess their own deployments to determine exposure — default severity is high for infrastructure that runs ospfd and exposes OSPF adjacency to untrusted or partially-trusted hosts.

---

Affected versions and vendor status​

• Affected FRR range: v4.0 through v10.4.1 inclusive. This version range is cited by NVD/OSV and vendor advisories.
• Upstream PR and commits: FRRouting accepted a patch addressing the crash (PR #19480, with commits referenced in the public issue/pr discussion). The patch adds safety checks for the VTY context and related dump routines. Administrators should consider source tree commits and packaged releases that incorporate these fixes.
• Distribution tracking and remediation status: Major distributions and vendors (Ubuntu, Debian, SUSE and others) have published advisories and OSV/NVD entries. In some cases vendors have deferred or backported fixes selectively; always consult your distro/security tracker for the exact package mapping and changed versions. For example, Ubuntu’s security page lists affected package statuses and shows that fixes were deferred for several release lines pending backport decisions.

Important operational note: Do not rely solely on the numeric FRR version listed in a CVE. Vendors frequently backport patches or apply different packaging policies; verify the vendor changelog or security advisory for the specific package build installed in your environment.

---

Exploit / PoC status — what is verified and what is not​

• The FRR project issue and PR provide a reproducible test case in the issue description (Mininet topology, sample configs, debug toggles) that shows ospfd crash behavior when an Opaque LSA is received while detailed packet dumping is enabled. This provides a clear reproduction recipe for researchers and maintainers.
• Several vulnerability aggregators and trackers report that a proof-of-concept (PoC) or exploit code exists on public code servers. However, a thorough search of public repositories and the FRRouting project pages does not produce a canonical, well-documented exploit repository under the CVE identifier at the time of this write-up. Some aggregator summaries may have pulled or referenced ephemeral PoC code or user-contributed snippets; these claims should be treated cautiously until a vetted PoC is located and validated.

Cautionary guidance:

• Assume a skilled tester can reproduce the crash if they have network adjacency and the ability to send crafted OSPF packets, especially when debug packet dumps are enabled.
• Do not download or run untrusted PoC exploit code from unknown sources; PoCs can carry additional risks or be intentionally malicious.
• If a public PoC appears, treat it as a high-priority trigger for defensive action (patch, mitigate), but verify its provenance and scope before sharing or executing it in production-like environments.

---

Detection and monitoring — what to look for​

• Kernel and process logs: ospfd crash traces, core dumps, and watchdog restarts. Check systemd/journald entries and any supervisor logs for repeated ospfd terminations. Collect and preserve core dumps where feasible for forensic analysis.
• OSPF-specific indicators: sudden loss of OSPF adjacencies, route withdrawal events, or rapid route flapping that correlates with ospfd process restarts. Monitor control plane telemetry (SNMP traps, telemetry streams) for unexpected OSPF events.
• Debugging settings: detect whether debug ospf packet all send/recv detail or similar verbose OSPF packet dump levels are enabled in running configs. These settings expand the attack surface and should be disabled in production unless troubleshooting under controlled conditions.
• Network-level logs: capture and analyze OSPF packets (pcap) to identify suspicious Opaque LSA content or repeated malformed LSAs from the same source — but be mindful that packet captures themselves can be voluminous; focus on OSPF adjacency peers and local segments.

---

Mitigation and remediation guidance​

Immediate actions (triage):

• Disable detailed OSPF packet dumps in production.
• Remove or disable debug ospf packet all send/recv detail and other non-essential debug options until you can safely test and upgrade. Detailed logging exposes the vulnerable code path and increases exploitability.
• Inventory and prioritize:
• Identify devices and hosts running FRR/ospfd (v4.0–10.4.1) and classify by criticality and exposure (edge routers, core routers, cloud VMs, virtualized network functions). Use your CMDB or package manager inventory to map package versions to hosts.
• Apply upstream or vendor patches:
• If your vendor or distribution has published a fixed package, apply it following your change control. If you maintain FRR from source, pull the upstream commits from the FRR PR that address the crash (PR #19480) and rebuild after QA validation. Confirm the fix is present in the installed binary by checking package changelogs or FRR commit history.
• Compensating controls when patching is delayed:
• Restrict network access to OSPF adjacencies: use ACLs, control-plane policing (CoPP), or management VLAN segmentation to limit who can send OSPF packets.
• Limit ability to enable debugging across automation and management systems (ensure debug toggles are gated by change control).
• Monitor for repeated ospfd crashes and automate alerting for process restarts or route withdrawals.

Patch and verification checklist:

• Confirm patch or fixed package presence in your distribution’s security advisory and package changelog.
• Test upgrade in staging with a trimmed topology and validate OSPF adjacency stability and route exchange before rolling to production.
• After patching, re-enable necessary debug settings only under controlled test windows and with packet capture and monitoring active.

Vendor nuance: Some distributions may choose to defer backporting or bundle the fix into a cumulative update; therefore, always consult the vendor-specific advisory (Ubuntu, Debian, SUSE, etc. rather than assuming immediate availability of a fixed package.

---

Operational recommendations and hardening (prioritized)​

• Turn off unnecessary debug flags in production. Debugging features that expose internal state often run code paths not meant for normal data-plane handling and increase risk.
• Isolate routing control planes: place management and routing adjacency interfaces on dedicated control-plane networks; apply ACLs restricting which hosts can form adjacencies.
• Harden automation: ensure configuration management and automation tools do not flip debug settings without human review.
• Centralize logs: push router logs and supervisor events to a centralized logging/SEIM system for trend analysis and to spot repeated ospfd crashes.
• Test upgrades: include FRR upgrades in scheduled maintenance windows and maintain known-good backups of route and configuration data.
• Monitor for PoC activity: if a public PoC appears, treat it like an “indicator of imminent exploitation” and accelerate patching and protective controls.

---

Strengths of the upstream response and residual risks​

Strengths:

• Upstream FRR maintainers created a focused patch that adds defensive checks rather than broad refactoring, which reduces regression risk for an important control-plane component. The PR and commits demonstrate a pragmatic fix path that keeps normal functionality intact while eliminating the crash trigger.
• Multiple independent vendors and trackers have cataloged the CVE quickly, providing guidance and mapping to distribution packages; that helps administrators locate vendor-specific fixes or workarounds.

Residual risks and caveats:

• Detection complexity: because the vulnerable path historically required debug dumping, some deployments may never enable it in production — yet automated or temporary diagnostic sessions create windows of exposure.
• Patch lag: many vendors may delay or selectively backport the fix; some distributions list the issue as “deferred” pending upstream stabilization. Admins must track vendor advisories closely.
• Chained exploitation: while this CVE is primarily a DoS, kernel and userland crashes can be combined with other flaws in a complex chain; defenders should not treat DoS-only claims as inherently low-risk in critical infrastructures.

---

Practical incident-response playbook (short checklist)​

• Immediately verify whether detailed OSPF debugging is enabled on any routers; disable it if found.
• Inventory FRR versions and identify devices in the vulnerable range (v4.0–10.4.1).
• Apply vendor-supplied fixes or upstream commits (PR #19480) in staging, validate, then roll to production.
• Apply network-level mitigations: ACLs limiting OSPF adjacency peers, control‑plane rate limiting.
• Monitor logs for ospfd restart patterns and capture pcaps of suspicious OSPF packets for analysis.

---

Conclusion​

CVE-2025-61106 is a significant availability-focused vulnerability in FRRouting’s OSPF daemon that demonstrates how diagnostic or debug code can expand an attack surface. The underlying cause — a NULL pointer dereference when dumping OSPF packet/LSA details — is straightforward and addressed upstream with defensive pointer checks and safer logging fallbacks. However, the presence of the bug across many released FRR versions and the high operational impact of an ospfd crash mean operators must act: disable unnecessary debug flags, inventory and prioritize vulnerable hosts, and install vendor or upstream fixes as soon as possible.
Key takeaways:

• Treat this as a high-priority availability risk for network control planes running ospfd.
• The most immediate mitigation is to avoid enabling detailed OSPF packet dumps in production; the structural fix is to deploy the patched FRR build or vendor-supplied package that contains the upstream correction.
• Monitor your environment for ospfd crashes, preserve core dumps for analysis, and consult your vendor’s security advisories for distribution-specific guidance and package mappings.

Administrators should treat this CVE as a prompt to re-evaluate debugging practices and control-plane exposure policies: debugging tools intended for troubleshooting can become attack vectors if not tightly controlled.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center