FRRouting has a serious denial-of-service bug — tracked as CVE-2025-61103 — that allows a crafted OSPF packet to crash the ospfd process via a NULL pointer dereference in ospf_ext.c, and operators should treat any running FRR instances that have OSPF debugging enabled as high-priority for mitigation and patching.
Background / Overview
FRRouting (FRR) is a widely used open-source routing suite that implements OSPF, BGP, IS-IS and other routing protocols. On October 27–28, 2025 multiple public vulnerability trackers and the FRRouting project recorded a family of related NULL pointer dereference defects in the OSPF daemon (ospfd). One of these defects, assigned CVE-2025-61103, is rooted in the function show_vty_ext_link_lan_adj_sid inside ospf_ext.c and can be triggered when detailed OSPF packet dumping is enabled. The resulting fault causes ospfd to crash, producing a full loss of the OSPF control-plane on the affected host. Key takeaways:
- Affected FRRouting versions: v4.0 through v10.4.1 (per public trackers).
- Root cause: NULL pointer dereference in OSPF packet dump code paths (vty context not validated).
- Practical precondition: the operator must enable detailed OSPF packet debugging (e.g., debug ospf packet all send/recv detail) for the vulnerable code path to be exercised in common scenarios.
- Immediate risk: Denial of Service (ospfd crash) and consequent routing disruption for impacted routers.
Technical analysis
What exactly is wrong?
The vulnerable code paths live in FRR’s ospfd OSPF implementation. When the daemon is configured to dump detailed packet information — often via VTY with the command string shown in public reports — ospfd will attempt to print or display detailed fields for incoming OSPF LS Update packets that include
opaque LSAs. Under certain packet shapes the code assumed a valid VTY context or associated show
* helper would be present and dereferenced a pointer that could be NULL. The missing check leads to a NULL pointer dereference and an immediate crash of the ospfd process. The upstream patch (merged into the project's master branch) remedies the issue by adding explicit NULL checks for the VTY pointer and by diverting output to the zlog logging path when VTY isn't available. The patch set includes a small number of defensive changes across related show* functions to ensure safe handling of opaque LSA dumping.
Reproduction and prerequisites
Researchers who reported the issue included a reproducible lab recipe: two FRR routers linked in a Mininet topology, with detailed OSPF packet debug enabled on one side, and an LS Update containing an opaque LSA sent from the neighbor. That particular scenario reliably produces the crash on the vulnerable binaries. This shows the exploit is
network-oriented (an OSPF packet triggers it), but it still requires the ability to send OSPF packets that reach the target’s OSPF processing context — typically an adjacent router or a host that can inject OSPF into the same domain.
Exploitability, scope and attacker model
- Attack vector: network-level injection of crafted OSPF packets. NVD and other trackers list the vector as network-reachable, but practical exploitation requires access to the OSPF domain (adjacency or a compromised peer).
- Privileges required: none on the target host; privileges are required only to be able to send packets that reach ospfd’s input processing.
- Complexity: low if preconditions are met (debugging enabled and packet reachability); otherwise, moderate because most production systems do not run with this verbose OSPF packet dumping enabled on production-facing interfaces.
- Real-world exposure: non-negligible in multi-tenant or lab/management networks where OSPF debug is enabled, and in situations where an attacker can gain adjacency or inject packets into the routing domain. Public EPSS and telemetry indicate limited observed exploitation to date, but that can change quickly once exploit recipes are shared.
What was changed upstream (the fix)
Developers merged PR #19480 into the FRR master branch; the commit series adds null checks before dereferencing the VTY context, and when VTY is absent the code uses the zlog debug logger to dump packet details instead of attempting to use vty*out. The change is intentionally small and defensive: it converts a crash path into a controlled logging path. The fix covers several related show** functions, not just the single symbol called out in CVE-2025-61103. Operational implication: the patch is low-risk from a functionality perspective (it does not change routing behavior), but it must be present in the deployed binary or backported package to neutralize the crash trigger.
Impact assessment
Operational impact
A crashed ospfd produces an immediate loss of OSPF routing on that host. In many deployments ospfd is the primary or only process providing dynamic intra-domain routing — its crash can:
- Drop OSPF adjacencies and cause route withdrawal, potentially disconnecting subnets.
- Trigger failover or reconvergence events that spike control-plane and data-plane churn.
- Break forwarding in edge or aggregation routers until the daemon is restored or the host is rebooted.
Because the attack results in
loss of availability rather than data theft or privilege escalation, the operational risk can still be severe: routing blackholes, multi-site outages and outage cascades in tightly-coupled networks are plausible. Public trackers assign a
High severity (CVSS v3.1 base ≈ 7.5) for the worst-case exposure scenarios.
Exposure patterns that matter
- Systems running FRR versions in the affected range that have debug ospf packet all send/recv detail enabled.
- Devices that accept OSPF packets from untrusted neighbors or management networks (for example, multi-tenant router hosts, lab/test environments, or misconfigured edge links).
- Hosts or containers that run FRR with accessible OSPF interfaces that might be reachable by attacker-controlled VMs or compromised neighbors.
Debian and other distro trackers show many packaged FRR versions remain marked vulnerable pending backports or upstream packaged fixes, so package managers and distribution images should be checked carefully for vendor mappings.
Detection and indicators
Practical signals to detect attempted exploitation or hits:
- Sudden ospfd process termination or repeated crashes; watch systemd/unit logs for ospfd restarts.
- OSPF adjacency state changes immediately preceding process crash events.
- Kernel or system logs showing process exit or core dump generation originating from ospfd.
- If you have centralized logging: repeated zlog debug messages about OSPF packet dumps that precede the crash can indicate an exploit attempt against verbose debug paths.
Suggested immediate checks:
- Verify if the debug command is enabled in persistent configs or via VTY sessions. The exact command in reports is: debug ospf packet all send/recv detail.
- Check ospfd logs (or zlog output) and system journal for crash traces and timestamps.
- Inventory FRR versions in your estate (vtysh -c 'show version' or distribution package queries) and map them against the affected ranges.
Immediate mitigation steps (short-term actions)
- Disable the offending debug setting immediately on any production devices:
- From VTY: run the corresponding "no" command to disable packet dumping (for example, "no debug ospf packet all send/recv detail"). This removes the easy trigger in many environments.
- If disabling debug is insufficient or not possible, isolate devices physically or logically from untrusted OSPF peers:
- Restrict adjacency formation via interface filters, passive-interface, or OSPF area segmentation.
- Block OSPF multicast addresses (224.0.0.5/6) from untrusted links where safe to do so.
- Where possible, apply access controls so only trusted management addresses can open VTY sessions or toggle debug options.
- If a device has already crashed, collect crash artifacts (core dumps, ospfd logs, zlog output) and preserve them for postmortem and patch verification.
- Schedule an emergency maintenance window to roll fixes or compile patched binaries if vendor packages are not yet available.
Permanent remediation (patching and verification)
- Upstream change: the fix was merged to FRRouting’s master branch (PR #19480). Operators should obtain a patched FRR binary that includes the PR or apply the small fixes themselves.
- Vendor/distribution packages: monitor your distribution’s security tracker and FRR packaging feeds. Some distros have deferred fixes in certain release channels; for production systems prefer vendor-backed, tested package updates rather than ad-hoc local builds unless that is your standard operating procedure. Debian’s tracker and other distro advisories list the CVE and show status per release — verify the exact fixed package version before rolling out.
- If an official package containing the fix is not yet available:
- Pull the specific commit(s) from PR #19480 and apply to your local FRR source tree.
- Rebuild FRR in a staged environment and run OSPF regression tests (adjacency formation, route exchange, LLDP/IGP interactions).
- Roll to a canary device and validate stability before mass deployment.
- Verification after patching:
- Confirm the deployed binary contains the commit (vendor changelog, package changelog or git commit hash).
- Re-enable normal logging and ensure no unexpected ospfd crashes occur under identical test traffic profiles that previously triggered the crash.
Risk matrix and prioritized action list
- Immediate (within hours)
- Disable "debug ospf packet all send/recv detail" everywhere in production.
- Block OSPF from untrusted networks and verify adjacency filters.
- Preserve logs and any core dumps from past crashes.
- Near-term (24–72 hours)
- Inventory installed FRR versions; identify hosts in the affected range v4.0–v10.4.1.
- Confirm whether vendor packages include the upstream fix; if not, plan local patching or staged builds.
- Harden VTY and management-plane access controls.
- Medium-term (1–2 weeks)
- Deploy vendor/packaged fixes to prioritized network devices (edge routers, aggregation points, multi-tenant hosts).
- Test failover and reconvergence under controlled load after patching.
- Long-term
- Re-evaluate debug policies: prohibit production enabling of verbose packet dumps unless during scheduled maintenance windows.
- Centralize and harden management-plane access and implement change-control for debug-level toggles.
Why this matters to network operators
Even though the bug is a NULL pointer dereference (a classical robustness defect), the consequence in routing infrastructure is severe: loss of dynamic routing connectivity can cascade into operational outages. The specific dependence on a debug setting means the vulnerability has a higher chance of being exploited in lab, test, or misconfigured environments — but production environments that enable detailed debugging for troubleshooting or monitoring are at real risk. Public advisories and trackers have rated the vulnerability high and recorded the upstream patch; however packaged vendor updates may lag, so pragmatic mitigation and fast inventory are essential.
Detection rules and hunting guidance for SOC teams
- SIEM rules:
- Alert on ospfd process exit/termination events or repeated restarts within a short window.
- Correlate sudden BGP/OSPF route withdrawal events with ospfd crashes.
- Flag any configuration changes that add "debug ospf packet all send/recv detail" to running configuration.
- Network telemetry:
- Monitor unexpected bursts of OSPF opaque LSA traffic or malformed LSA patterns in lab/test networks; these could be reconnaissance or attempted exploitation.
- Incident response:
- If an ospfd crash is linked to suspected exploitation, isolate the device, collect vmcore/core (if available), and preserve the zlog output; apply patch and run regression tests before reintroducing the device to the production network.
Frequently asked operational questions
- Can this be exploited remotely from the Internet?
- OSPF is designed as an interior gateway protocol and typically requires adjacency or link-local reachability. In practice, exploitation requires packet reachability into the OSPF processing domain (adjacent link or compromised peer). That said, untrusted networks that incorrectly forward OSPF packets or misconfigured management routes can expose devices. Public trackers label the vector as network; the practical requirement is packet reachability to the target’s ospfd.
- Is a reboot necessary after remediation?
- If the process was crashed, restart ospfd after applying the patch or rolling back the debug setting. For kernel-level or system-level crashes (not typical here), a host reboot would be required, but the FRR fix itself is at user-space daemon level and does not require a host reboot unless packaging constraints dictate it.
- Are there public exploit proofs-of-concept?
- Public trackers and security databases report reproducible crash recipes in issue reports (repro steps) but there is no widely-circulated weaponized exploit kit as of the latest advisories. EPSS and telemetry indicate limited exploitation activity, but that can change once PoCs are broadly published.
Conclusion
CVE-2025-61103 is a high-consequence, low-complexity vulnerability in FRRouting’s ospfd packet-dumping code that can crash the OSPF daemon and produce routing outages. The fix is compact and upstreamed, but packaged vendor updates may lag and the bug’s exploitability is highly dependent on configuration (notably,
debug ospf packet all send/recv detail). Network operators should immediately disable detailed OSPF packet debugging in production, inventory FRR instances, and apply the upstream patch or vendor-supplied package as soon as it is available. Treat any FRR devices that accept OSPF packets from untrusted networks or that run verbose debugging as high-priority for remediation.
Source: MSRC
Security Update Guide - Microsoft Security Response Center