FRR OSPF CVE-2025-61107 Patch Prevents NULL Pointer Crash

FRRouting has been flagged for a serious Denial-of-Service hole: a NULL pointer dereference in OSPF packet handling (CVE-2025-61107) that can crash the ospfd daemon when a crafted LSA Update containing an opaque LSA is processed, and the problem was patched upstream via a targeted set of checks added to the OSPF dump code.

Background​

FRRouting (FRR) is an open-source routing suite widely used in routers, network appliances, and cloud networking stacks to implement protocols such as BGP, OSPF, IS-IS, and others. The CVE record for CVE-2025-61107 identifies a NULL pointer dereference in the OSPF code path tied to the show_vty_ext_pref_pref_sid logic inside ospf_ext.c. The defect is triggered when the OSPF daemon is configured to dump packet details (for example, the command debug ospf packet all send/recv detail) and then receives a specially crafted LSA Update that includes an opaque LSA; during the dump routine, a missing check leads to dereferencing a NULL pointer and terminates the daemon. Public vulnerability trackers (NVD, OSV) list affected FRR versions as v4.0 through v10.4.1 inclusive, and the community fix was landed in the FRR project repository as a small set of defensive checks added to ospf_ext.c and related OSPF opaque-LSA dumping helpers. The upstream fix was committed in August 2025 and later included in FRR release builds.

---

Why this matters: OSPF, opaque LSAs and the NULL dereference risk​

• OSPF is a link-state interior gateway protocol used to share routing information inside a single routing domain. LSA (Link State Advertisement) messages are the mechanism OSPF uses to exchange topology and state.
• Opaque LSAs are a special LSA subtype used to carry non-standard or extension data. Because they are processed by OSPF code paths that may include debug/dump routines, they represent a low-footprint attack surface when implementations attempt to parse or display their contents.
• A NULL pointer dereference in a service daemon that runs with elevated privileges (routing daemon interacting with kernel sockets) typically results in process termination. For routing daemons, loss of the process can mean abrupt routing disruption and, depending on the platform and orchestration, potentially much broader network impact. This class of failure is an availability-first vulnerability and is covered by CWE-476.

The FRR issue is practical to trigger only when the OSPF daemon is configured to produce detailed packet dumps (a common operator troubleshooting mode), but the condition is non-trivial because an attacker merely needs to deliver a crafted LSA Update (which can be sent from a network-adjacent host capable of injecting OSPF packets). Several vendor trackers score the vulnerability as High with a CVSS v3.1 base score of 7.5 (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

---

Technical analysis: what went wrong and how the fix works​

The root cause, in plain engineering terms​

When ospfd is instructed to show detailed contents of packets (VTY output or zlog), the dump path calls a family of show_ helpers to format and print LSA contents. In the opaque-LSA dump routines the code assumed that the VTY context (a pointer used to write formatted output to the CLI or vty log) and certain internal helper structures were always present. If the code path ran in a context where VTY was absent or certain LSA internals were NULL (such as malformed or intentionally crafted opaque LSA payloads), the code would dereference a NULL pointer and crash the process. The downstream symptom is an immediate ospfd termination and an interruption of OSPF routing functions.

What the upstream patch changed​

The patch adds defensive checks around the VTY pointer and the opaque-LSA parsing helpers. When VTY is present the code continues to use vty_out, but if VTY is NULL the code now falls back to logging the same information via zlog, or otherwise handles the missing object gracefully instead of dereferencing it. The change is surgical and focuses on validating pointers—this is a classical defensive-programming fix for a NULL-reference bug. The PR that introduced the fix shows the specific functions guarded and the commits that were merged.

Attack vector and prerequisites​

1. The target must run a vulnerable FRR/ospfd binary built from a version between v4.0 and v10.4.1 inclusive, or a distribution package containing the same vulnerable source code.
2. The OSPF configuration must include the debug packet detail setting that causes the vulnerable dump code to run (e.g., debug ospf packet all send/recv detail). Without this configuration, the vulnerable code path is not exercised during normal OSPF operation in most configurations.
3. The attacker must be able to inject or transmit an LSA Update containing an opaque LSA to the victim OSPF instance. In many enterprises that means adjacent network access or ability to spoof OSPF packets on a segment; in multi-tenant or misconfigured environments this is more feasible than on hardened infrastructures.

Practical exploitability​

While the vulnerability can be triggered over the network (no authentication or privileged access required), successful exploitation typically relies on two operational realities:

• The presence of the debug dump configuration (sometimes enabled for troubleshooting and occasionally left enabled in production).
• The ability to deliver OSPF packets into the routing domain (often local network access).

Because those conditions are not universal, many vendors and distributions rate the exploitability and practical exposure as significant but constrained; nevertheless, the impact is direct and severe when the conditions are met because ospfd termination means loss of route advertisement/update processing.

---

Impact assessment: availability, operational risk and attack consequences​

• Availability: Immediate — the ospfd process crashes and stops participating in route calculation and message handling, causing OSPF neighbors to experience route flapping or loss of reachability for affected prefixes. The effect can be ephemeral (while an attacker injects packets) or persistent if process restarts are slow or if orchestration does not automatically recover adjacency state.
• Operational risk: In distributed networks that rely heavily on OSPF for connectivity (data centers, ISP edge, backbone segments), loss of ospfd on one or more nodes can trigger routing instability, traffic blackholes, or failover behavior that impacts services across multiple systems.
• Collateral effects: Routing convergence, route redistribution and external control-plane interactions can magnify the outage timeline, especially in complex topologies.
• Confidentiality/Integrity: Not directly impacted by this vulnerability. The defect is an availability issue; there is no indication of arbitrary code execution or data leakage from the bug itself.

Note: NULL dereferences in network-facing daemons are almost always availability issues rather than covert privilege escalation vectors, but they can be exploited as part of composite attacks (for example to cause predictable network disruption during a broader campaign). General discussions of NULL dereference severity and kernel/userland differences underline how availability-first bugs should be treated as operationally critical.

---

Detection, indicators and forensic signals​

Immediate signs to watch for​

• Unexpected termination or repeated restarts of ospfd processes; crash traces pointing to ospf_ext.c or opaque-LSA dump functions in logs.
• OSPF adjacency flaps or sudden withdrawal of routes that the affected router was advertising.
• System logs (journalctl, syslog) containing a stack trace or zlog entries indicating a NULL pointer or segmentation fault in ospfd.
• CLI inability to run OSPF debug output or unexplained errors when enabling packet dump features.

Hunting and monitoring tips​

• Add detection rules to your logging pipeline to flag ospfd crashes and to correlate those with times when debug ospf packet all send/recv detail was active or recently toggled.
• Network-based detection: monitor for anomalous LSA Update packets and opaque-LSA payloads arriving from unexpected peers or interfaces.
• For managed platforms and distributions, watch vendor security advisories and package updates; package changelogs will often reference the CVE and the specific commits.

---

Mitigation and remediation steps​

Immediate mitigations (if you cannot patch right away)​

• Disable verbose OSPF packet debug (for example remove or avoid debug ospf packet all send/recv detail) on production routers. Because the vulnerability is exercised by the dump code, removing that configuration significantly reduces the attack surface.
• Apply network filtering rules to block OSPF LSA update traffic from untrusted or external sources at network boundaries and edge devices. Restrict OSPF to trusted neighbors only (use interface filtering, passive interfaces where appropriate, and ACLs).
• If you run FRR inside containers or virtualized instances, restrict who can inject packets into the routing plane (isolate management and control-plane networks). Several advisories recommend blocking crafted LSA Updates at ingress points until a patch can be applied.

Patching and long-term remediation​

• The upstream FRR repository merged a fix that adds robust NULL checks and safer logging fallback behavior (commit series culminating in fdd957408605d4a1766225630aafc7e6b7c3daf3). Operators should upgrade to a release that includes that commit. The change was merged in August 2025 and the FRR project published release builds later in 2025 (for example FRR 10.5.0).
• If your vendor/distribution has packaged FRR, apply vendor-supplied updates. Debian, Ubuntu, SUSE and other vendors have tracked the CVE and their security trackers list package statuses and recommended fixed versions. Confirm your specific package and the package changelog for the fix mapping before updating.
• For environments that require extended testing, consider building FRR from the upstream commit that contains the fix and validating in a staging environment before rolling to production; ensure coordinated maintenance windows for routed nodes to limit convergence issues.

---

Vendor responses, release timeline and patch availability​

• The upstream FRR PR that fixes the issue was authored and merged in August 2025; the commit description and the PR conversation document the changes and the reasoning for the defensive checks.
• FRR published new releases later in 2025 (for example, FRR 10.5.0 in November 2025), and the project’s release cadence has a history of backporting and issuing bugfix releases for active 10.x branches. Operators should review FRR release notes for explicit mention of the commits or bug IDs they map to.
• Distribution trackers (Debian security tracker, SUSE security pages, etc. list CVE-2025-61107 and track fixed package versions. In some distributions fixes are deferred for specific release channels and operators must consult package lists or vendor advisories for exact fixed-version names.

Important operational note: where distributions or vendor packages lag, the upstream commit is authoritative and may be used to backport or build interim packages — but any in-house build should be accompanied by testing for stability in your network topology.

---

Practical checklist for network operators (actionable steps)​

1. Stop: Immediately check whether any routers in your estate run FRR versions between 4.0 and 10.4.1 and whether debug ospf packet all send/recv detail is active.
2. Disable: If packet-dump debug is enabled in production, disable it and avoid enabling it while unpatched.
3. Patch: Schedule and apply vendor-supplied FRR packages that contain the upstream commit or upgrade to a release that includes the fix (FRR 10.5.0 and vendor-published backports where offered).
4. Network controls: Add ACLs/filters to limit who may send OSPF LSA updates to your routers; restrict OSPF adjacency formation to known, authenticated neighbors.
5. Monitor: Configure logging/alerting for ospfd crashes and unexpected process exits; correlate with network packet traces for opaque-LSA changes.
6. Test: After patching, validate OSPF neighbor stability, route recalculation and failover behavior in a non-production window.
7. Document: Record the affected devices, packages and mitigations in your change management and vulnerability inventory.

---

Balanced view: strengths of the response and potential residual risks​

• Strengths: The upstream FRR fix is small and focused; it addresses the root cause by adding missing NULL checks and safe logging fallbacks. The patch was integrated into the project and referenced by multiple vulnerability trackers, so a canonical remediation path exists. Public advisories provide crisp remediation guidance and CVE tracking for vendors and operators.
• Residual risks:
  • Operational misconfiguration (leaving debug dumps enabled in production) remains a recurring vector that can be exploited across different versions or forked builds.
  • Long-tail vendor images, embedded appliances or cloud marketplace images may take longer to receive patches; operators must validate their build provenance and package changelogs.
  • The vulnerability class—NULL dereference in protocol parsing—is easy to re-introduce elsewhere if rigorous defensive coding and fuzzing are not applied. Systematic hardening, improved fuzz testing of control-plane parsing, and stricter default configurations (avoid enabling verbose dumps in production) are structural mitigations.

Where claims are not fully verifiable: public trackers list the fix and the commit, but mapping to every specific vendor package and version requires inspection of vendor changelogs; operators should confirm the patch mapping for their distribution rather than assume an automatic backport. This caveat reflects the usual vendor backport variability.

---

Conclusion​

CVE-2025-61107 is an availability-focused vulnerability in FRRouting’s OSPF dump code that can crash ospfd when handling crafted opaque LSAs if verbose packet dump debugging is enabled. The defect was identified, fixed in the FRR codebase via defensive NULL checks, and tracked by major repositories and vendors. Administrators should treat the issue as operationally urgent: verify affected versions in your environment, disable detailed OSPF packet debug in production, apply vendor or upstream patches, and implement network-level controls to limit exposure to malformed or adversarial LSA traffic. Timely patching combined with conservative debug practices and packet filtering will mitigate the direct risk and restore routing resilience.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center