CVE-2025-61104: FRR OSPF NULL Pointer DoS and Patch Guide

FRRouting's OSPF implementation contains a NULL-pointer dereference that can be triggered by a crafted OSPF packet, allowing remote attackers to crash the OSPF daemon (ospfd) and cause a Denial of Service (DoS) for routers and appliances using vulnerable FRR releases.

Background​

FRRouting (FRR) is an open-source routing suite widely used in network appliances, virtual routers, enterprise edge devices, and cloud networking stacks. Its OSPF (Open Shortest Path First) daemon, ospfd, handles OSPF adjacency and link-state distribution. On October 28, 2025, public vulnerability records cataloged CVE‑2025‑61104 — a NULL pointer dereference in the function handling unknown TLV (Type-Length-Value) dumping within the OSPF opaque LSA handling code. The vulnerability affects FRR releases from v4.0 through v10.4.1. The flaw is notable because it permits a remote, unauthenticated attacker with the ability to send crafted OSPF packets to crash ospfd. This is not a subtle, local-only stability bug; the protocol-level exposure means routers participating in OSPF adjacency across a network can be targeted, potentially causing routing disruption across an affected topology.

---

What exactly is CVE-2025-61104?​

The technical root cause​

At its core, CVE‑2025‑61104 is a classic NULL pointer dereference (CWE‑476). When FRR's ospfd is configured to dump detailed OSPF packet information (for example when using the debugging setting debug ospf packet all send/recv detail), the code path responsible for rendering opaque LSA details attempts to use a VTY (virtual terminal) context or related pointers without verifying they are valid. Under certain crafted packet conditions — specifically malformed or specially structured opaque LSA TLVs — the code reaches a path where a pointer expected to be non-NULL is actually NULL and is dereferenced, causing a crash in the daemon. The maintainers’ patch adds defensive checks: verify the VTY context and related pointers before calling the show/dump routines; if the VTY context is not available, fall back to logging via zlog rather than dereferencing NULL. This is a surgical fix that reduces crash risk by avoiding unsafe pointer dereferences during the debug/dump path.

Where the bug sits in the stack​

• Component: ospfd (OSPF daemon within FRR)
• Source file(s): ospf_ext.c / ospfopaque handling (show_vty_unknown_tlv / show_opaque_info_detail code paths)
• Trigger: Receiving a crafted OSPF LS Update containing an opaque LSA with malformed TLVs while verbose packet dumping is enabled.
• Consequence: Crash of the ospfd process (service termination), loss of OSPF routing on that node until daemon is restarted or device recovered.

---

Affected versions and scope​

• Affected FRR versions: v4.0 through v10.4.1 (inclusive).
• Unaffected: Versions prior to 4.0 and versions that incorporate the upstream fix (see upstream commit / PR). Operators should treat any 4.0→10.4.1 deployment as potentially vulnerable until validated.

Because FRR is commonly bundled with network OS images and appliance firmware, the real-world population of vulnerable systems is wider than mere Git tags: vendors that ship FRR as part of their device stacks may need to push firmware or package updates. This makes tracking vendor advisories as important as tracking upstream releases.

---

Exploitability and impact​

Attack vector​

This vulnerability is exploitable over a network by crafting OSPF packets. OSPF is an interior routing protocol that is typically exchanged over multi-access networks and point-to-point links between routers. If an attacker can inject or relay OSPF packets into the adjacency domain of a vulnerable ospfd instance — for example, by being on a shared Layer 2 network, by compromising a neighbouring device, or by manipulating packet forwarding paths — they can trigger the crash without authentication. The practical attack surface depends on deployment:

• Traditional routed topologies with proper control-plane isolation are less exposed.
• Multi-tenant environments, misconfigured adjacencies, or devices that accept OSPF from untrusted networks are highly exposed.

Severity and operational impact​

• Impact type: Availability — ospfd process crash causes immediate routing interruption on the affected node. Because OSPF participates in distributed routing, node outages can cascade or cause traffic black-holing until routes reconverge.
• CVSS (community/aggregated): widely reported as High (CVSS v3.1 7.5 / vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) reflecting remote network attackability and high availability impact.

The condition can be:

• Sustained: repeated packet injections can keep the daemon down.
• Persistent: if the daemon crashes and the device does not automatically recover or restart the routing process, the outage may persist until manual intervention.

Real-world consequences​

• Loss of reachability for routed subnets.
• BGP or other protocol dependencies may experience instability if OSPF is used for next-hop decisioning.
• Network operations overhead (investigation, failover, manual recovery, firmware upgrades).
• Possible operational exposure for critical infrastructure (data center fabrics, provider edge routers) if not patched or mitigated.

---

The upstream fix and verification​

FRRouting maintainers accepted a contribution that introduces NULL checks and safer logging behavior when the VTY context is unavailable; the PR includes the patch and discussion of the code paths fixed. Operators should verify that the fix is present in their deployed code/builds — either by upgrading to a patched FRR release from the project or ensuring vendor-supplied images include the PR's commits. Upstream artifacts and aggregators (NVD, OSV, vendor trackers) list the PR and commits as the remediation. Administrators should cross-check the commit hash from the PR in their deployed FRR tree or ask vendors for explicit confirmation of the backport. Operational tip: package maintainers or device vendors often backport fixes instead of bumping major versions. When in doubt, request the exact upstream commit ID or patch notes from your vendor and validate the installed package changelog against that identifier.

---

Detection, hunting, and indicators of compromise​

Immediate signals to monitor​

• ospfd service crashes and restarts logged in syslog/journal.
• Kernel or process-level core dumps triggered by ospfd termination.
• Unexpected OSPF adjacency flaps correlated to timestamps where neighbor devices show no configuration changes.
• Unusual OSPF packets captured on the wire (opaque LSAs or malformed TLVs) during the time of a crash.

Maintainers report that the crash is deterministic when the crafted packet hits the specific dump code path; therefore packet captures during incidents are extremely valuable for diagnosing exploitation.

Detection guidance​

• Collect OSPF-related daemon logs (zlog, syslog, journalctl) and search for stack traces or backtraces referencing ospf_ext.c or show_vty_unknown_tlv.
• Correlate process crash times with packet captures from network taps or SPAN ports to identify suspicious LS Update messages with opaque LSA TLVs.
• For managed environments, use configuration management/monitoring to detect unexpected ospfd restarts and generate alerts.

---

Mitigations and recommended action plan​

Immediate mitigations (while you evaluate/patch)​

• If practical, restrict OSPF adjacency formation to trusted peers only. Enforce ACLs at the interface level to allow OSPF packets only from known neighbor addresses or networks.
• Disable or avoid enabling debug ospf packet all send/recv detail or other verbose packet-dump modes in production; the vulnerable path is triggered when detailed dumping of packet contents is performed. If debugging is needed, perform it in isolated lab environments only.
• If running in multi-tenant or cloud environments where tenants can affect Layer 2/adjacency traffic, limit tenant access to bridging or raw packet injection capabilities (tighten VLANs, restrict promiscuous mode, etc..

Patching​

• Prioritize upgrades of FRR instances that run versions v4.0 through v10.4.1 to a release that contains the upstream fix. If a vendor image includes FRR, contact the vendor and apply the vendor-supplied update.
• If distributing your own FRR builds, pull the patch/commit referenced in the upstream PR and rebuild. Confirm the commit hash is present in the built binary by checking package changelogs or git metadata attached to the build.
• Test patches in a staging lab with representative OSPF topologies before rolling to production to avoid regressions.

Long-term hardening​

• Use control-plane ACLs and management-plane isolation to ensure routing protocol traffic is strictly limited to authorized devices.
• Adopt a security-focused change control policy for routing daemons: avoid enabling debug/dump features on production devices and treat them as operationally sensitive.
• Maintain an inventory of vendor images and open-source components (like FRR) used in devices so CVE impact mapping and patch testing is efficient. The vendor-image gap is a frequent source of delayed remediation.

---

Why the fix is low-risk — and where residual risk remains​

Strengths of the remediation​

• The upstream changes are defensive checks and logging fallbacks rather than deep rewrites of protocol handling logic. That reduces the chance of functional regressions.
• The fix is small and targeted; it changes only the dump/render path to avoid dereferencing NULL when a VTY context is missing. This typically yields quick backports and fast vendor packaging.

Residual risks and caveats​

• Backport variance: vendors may apply different backport strategies. Some vendor images may not include the exact upstream patch or may modify it; always verify the commit ID or vendor advisory rather than assume version numbers.
• Detection gap: because this is a stability/availability bug (DoS), attackers may prefer silent repeated triggers that are hard to detect until significant routing disruption occurs.
• Operational exposure: any device that accepts OSPF packets from less-trusted networks — e.g., multi-tenant fabrics, certain SDN setups, or misconfigured peerings — remains at higher risk even after partial mitigations.

---

Checklist: What network operators should do now​

• Inventory FRR deployments and identify versions running between v4.0 and v10.4.1. Confirm whether the vendor images include FRR and, if so, ask the vendor for an explicit mapping to the upstream fix.
• Apply vendor-supplied updates or upgrade FRR to a build that contains the PR/commit that fixes the NULL dereference.
• Temporarily restrict OSPF packet ingress to trusted peers and disable verbose packet-debugging modes in production.
• Enable and centralize logging for ospfd restarts/crashes; capture packet traces for any OSPF-related outage.
• Validate fixes in a staging environment with representative OSPF adjacencies before broad rollout.
• Document and deploy control-plane ACLs and monitoring rules that detect opaque LSA anomalies.

---

Final analysis and takeaway​

CVE‑2025‑61104 is a high-impact but conceptually simple vulnerability: a NULL pointer dereference in FRRouting’s OSPF opaque‑LSA dump path that permits remote, unauthenticated Denial of Service when exploited by crafted OSPF packets. The issue is alarming because routing daemons are critical infrastructure components; their failure has immediate, network-wide consequences. The upstream fix is small and defensive, and multiple authoritative trackers and the FRR project have identified and remedied the code path. However, the real-world risk depends heavily on deployment topology and vendor patch cadence — operators should treat any FRR v4.0→v10.4.1 instance as urgent to remediate until they can verify the fix or apply compensating controls. Patch promptly, restrict OSPF adjacencies to trusted peers, and avoid enabling verbose OSPF debug/dump features in production — those three steps will sharply reduce exposure and restore routing stability in affected environments.

---

Conclusion
This vulnerability serves as a reminder that code paths used primarily for debugging or verbose output can become attack surfaces when they assume privileged—or always-present—context such as VTY. The practical lesson for operators is straightforward: keep network protocol implementations up to date, validate vendor backports, and treat debug/dump features as operational liabilities in production. Applying the upstream patch or vendor-provided update, combined with control-plane hardening, will secure affected FRR deployments and restore expected availability for OSPF-based routing.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center