FRRouting has been disclosed with a cluster of NULL-pointer dereference flaws that allow a remote attacker to crash the OSPF daemon (ospfd) by sending crafted OSPF packets; the most prominent of these is tracked as CVE-2025-61102 and affects FRRouting (frr) releases from v4.0 through v10.4.1, producing an immediate Denial of Service (DoS) against routing processes when triggered.
Background
FRRouting (commonly abbreviated
FRR or
frr) is an open-source routing suite used widely in routers, virtual appliances, cloud images, and Linux-based network appliances. It implements routing protocols including
OSPF,
BGP, and
RIP and is frequently deployed both as a component of vendor images and directly on Linux servers and virtual machines.
The CVE series published in late October 2025 documents multiple, closely related issues in the OSPF extension parsing code (file ospf_ext.c). These problems manifest as
NULL pointer dereferences inside functions used to format or dump OSPF packet contents (for example, the function show_vty_ext_link_adj_sid cited in CVE-2025-61102). The practical outcome is that a single malformed OSPF packet — or a class of OSPF packets crafted to hit the vulnerable code path — can cause the
ospfd process to crash or terminate, producing loss of routing control or interruption of forwarding decisions until the daemon is restarted or the host recovers.
Overview of CVE-2025-61102 and related issues
What the vulnerability is
- Vulnerability ID: CVE-2025-61102 (part of a family of CVEs in the same area).
- Root cause: Missing NULL checks in code that dumps OSPF packet and LSA details for output to VTY or logs; specifically, the vulnerable code assumes certain context or helper pointers (like a VTY context or show_opaque_info) are present. When the assumptions fail, the code dereferences a NULL pointer.
- Trigger: A crafted OSPF packet (or a malformed OSPF LSA/opaque LSA) that causes the code path to run. The issue is triggered when code paths that print detailed OSPF diagnostics are invoked.
Affected versions and scope
- Versions: FRRouting (frr) from v4.0 through v10.4.1 are reported affected. The upstream vulnerability records list those version bounds; distribution packages that ship those releases are therefore potentially vulnerable.
- Deployments at risk: Any router, virtual appliance, cloud image, or management host running an affected frr build and processing OSPF traffic — particularly devices that might accept OSPF packets from adjacent links or management networks — are within the attack surface. Distributions and vendors that bundle or backport FRR into their images should be validated for exposure.
Technical analysis — how the bug works
The vulnerable code path
The vulnerable functions live in
ospf_ext.c, which contains helpers used for producing human-readable output of OSPF entities (for VTY output and detailed debug logging). When
ospfd is configured with very verbose diagnostic options (for example the command
debug ospf packet all send/recv detail) the code attempts to format and print extra fields from OSPF packets and Opaque LSAs. Under certain malformed-packet conditions the code calls into formatting helpers without validating that the
vty context or corresponding helper objects exist; the missing validation leads to a NULL dereference during string assembly or structured printing. The maintainers’ patch enforces those checks and falls back to zlog logging when a VTY is unavailable.
Exploitation model and reachability
- Network-exposed vector: The vulnerability is network-triggerable — a crafted OSPF packet received on an interface processed by the OSPF daemon can reach the vulnerable code. That makes the vulnerability remotely reachable from adjacent OSPF neighbors or any host that can inject OSPF packets into the routing domain. Multiple trackers mark the attack vector as Network and the CVSS v3.1 vectors we see in public records are consistent with a high availability impact and low complexity for an attacker able to inject or manipulate OSPF packets.
- Runtime condition nuance: At least one authoritative analysis and the upstream patch discussion point out that the problematic code is exercised most commonly when detailed OSPF packet dumping is enabled — a diagnostic setting often used transiently during troubleshooting but not typically left on in production. That reduces general exposure on default configurations, but the vulnerability is nonetheless classified with a high impact because many operational systems do enable verbose logging in network debug windows, and embedded or appliance builds might expose the path differently.
Impact: denial-of-service vs. code execution
- Immediate impact: A deterministic crash of ospfd (NULL pointer dereference) leading to routing control-plane loss and potential forwarding disruption if neighbor adjacencies or redistributed routes are affected. CVE records consistently mark the primary impact as Availability (DoS).
- Escalation risk: Public analyses and vendor advisories do not present credible evidence that the NULL pointer faults result in arbitrary code execution. The bug is a robustness flaw rather than a heap overflow or type confusion that would more commonly enable RCE. That said, kernel-space or daemon crashes are operationally dangerous and can be composed into broader attack strategies (for example, repeated DoS to degrade observability or force failovers). Treat the immediate security risk as DoS with potential operational consequences beyond a single process crash.
What has been published and how FRR responded
- FRRouting maintainers accepted a pull request that introduces NULL checks and safer logging fallbacks for the affected code paths; the PR explicitly references the Opaque LSA dump and the conditions causing NULL dereference and ties back to issue investigation. The PR is visible in the FRRouting GitHub repository and contains the remedial code changes.
- Multiple vulnerability databases and distributors published CVE records that mirror the upstream description and list affected versions v4.0 through v10.4.1. Tracking pages (NVD, Debian, Ubuntu, SUSE, Tenable and third-party CVE aggregators) reflect consistent classification of this CVE family and reference the GitHub PR/issue for the fix. Administrators should assume the vulnerability has been accepted as valid across standard vulnerability feeds.
Detection, indicators, and hunting guidance
- Daemon crashes: The most direct indicator is repeated ospfd crashes, core dumps, or automatic restarts of the FRR service. Monitor systemd/journal logs for ospfd OOM/oops traces or unexpected exit/restart cycles.
- VTY / zlog traces: In some cases the crash will be observable adjacent to zlog entries where opaque LSA or debug dump code tried to execute; log lines that appear just prior to a crash can identify a suspicious OSPF packet dump attempt.
- Network-level telemetry: Look for anomalous OSPF LSAs or Opaque LSA floods from neighboring peers. If an attacker attempts to weaponize this flaw they will likely send repeated OSPF updates, so spikes in OSPF packets on management or adjacency links are a sign.
- Searchable IOCs: There are no simple static IOCs embedded in OSPF that uniquely identify the crash-triggering LSA; detection will therefore rely on behavioral and telemetry signals (daemon failures coincident with odd OSPF traffic patterns). Centralize logs and preserve core dumps for forensic analysis.
Mitigation and remediation
Definitive fix
- Apply the upstream patch or upgrade FRRouting to a fixed release once the FRR project publishes a release that contains the PR changes (the PR for the fix is already present in the FRRouting repository). Administrators should prefer vendor-packaged updates from their distribution rather than manually compiling where possible.
- If vendor packages are not yet available, obtain and apply the upstream patch as a stopgap in controlled images or test environments, then validate extensively before pushing to production. The GitHub PR provides the exact changes that close the NULL checks and the commit can be backported where necessary.
Interim mitigations (if immediate patching is not possible)
- Disable verbose OSPF packet dumps: Avoid enabling
debug ospf packet all send/recv detail or equivalent highly detailed diagnostic modes on production routers and servers. Public analysis indicates the vulnerable code path is often (though not always) exercised when verbose dumping is enabled. Turning off diagnostic packet dumps reduces exposure in many environments.
- Harden OSPF adjacency acceptance: Limit which neighbors can form adjacencies. Apply interface-level controls and ACLs so only authorized routers can exchange OSPF packets on management or transit links.
- Control-plane filtering: Where supported, implement control-plane policing or ACLs that limit malformed or unexpected LSA types from untrusted sources. Rate-limit control-plane traffic to reduce the feasibility of volumetric attempts to trigger the bug.
- Network segmentation: Isolate management and routing plane networks from general-purpose hosts. Segmentation reduces the ability of an attacker to inject OSPF packets in a way that reaches an affected instance.
Vendor and distribution status snapshots
- Debian and other distributions’ trackers list frr packages built from the affected upstream versions as vulnerable; package-level fixes vary by release and are tied to distribution changelogs. Administrators must consult their distribution’s security advisories for precise package versions to upgrade.
- Ubuntu classified CVE-2025-61102 with a priority marking and lists distribution-level status (in some releases fixes were deferred pending upstream resolution). Check the Ubuntu Security Notices for specific Ubuntu release guidance and fixed package mappings.
- SUSE lists the issue as pending with a moderate severity assignment in its tracker; vendor processing and backport decisions may vary.
Proof-of-concept (PoC) and exploitation status — caution and verification
- Several third-party aggregators and feeds claim that a public PoC exists on GitHub or list a “public PoC” flag for these CVEs. Some feeds index or mirror community exploit collections and may list PoC artifacts. These claims are not universally corroborated by the upstream FRRouting issue tracker or vendor advisories. Treat third-party PoC reports with caution: verify the PoC source, the exact target conditions, and whether the code requires a test lab to run safely.
- Authoritative trackers and enrichment platforms note no evidence of widespread in-the-wild exploitation at the time of disclosure, and some vendor commentary emphasizes that vulnerable code paths are often reachable only under specific diagnostic settings (which limits exposure on default production builds). That said, the absence of public exploitation reports is not proof of safety; targeted attackers or misconfigured networks may still be at risk.
Flag: any claim that a remote unauthenticated attacker can trivially escalate this to remote code execution is not substantiated in public, peer-reviewed advisories. The documented impact remains
denial of service (process crash), and statements implying RCE should be treated as speculative unless and until authoritative exploit analyses demonstrate memory-corruption primitives beyond a NULL dereference.
Operational recommendations — prioritized checklist
- Immediately inventory all assets that run FRRouting / frr and identify packages that map to upstream releases v4.0 through v10.4.1. Prioritize network-edge routers, virtual appliances, cloud guest images, and any device that processes OSPF adjacency traffic.
- For each affected asset, confirm whether debug-level OSPF packet dumps are enabled. If they are, disable them on production systems until you can apply a patch or update.
- Apply upstream or vendor-supplied patches as soon as they are available and validated in your staging environment. Prefer vendor-signed packages or distribution kernel/daemon updates where possible.
- Where immediate patching is impractical, apply temporary mitigations:
- Restrict OSPF adjacency formation to authorized neighbors.
- Implement control-plane ACLs and rate-limiting for OSPF LSAs.
- Harden management plane access and monitor for anomalous OSPF LSA traffic.
- Monitor logs centrally for ospfd crashes, restarts, and unusual OSPF LSA volumes. Retain core dumps and zlog output for forensic analysis if unexplained crashes occur.
- For cloud and virtualized infrastructures, treat tenant-adjacent attack models seriously: a tenant that can inject or forge OSPF-like traffic toward a shared routing process is an exploitation path. Enforce tenant isolation and packet filtering in hypervisor or virtual-switch configurations.
Critical assessment — strengths, risks, and unanswered questions
Notable strengths in the response
- The issue was triaged and a focused upstream patch was proposed and merged quickly; the fix is surgical (adds NULL checks and safer logging fallback behavior) and carries low risk of functional regression. The presence of an explicit PR and tested commits is a positive sign for rapid remediation.
- Multiple vulnerability databases and distributors rapidly mirrored the CVE records, enabling security teams to discover affected assets via scanner databases and intrusion-prevention rules. That cross-indexing reduces the “blind spot” window for administrators.
Potential risks and operational caveats
- The attack surface is network-facing for OSPF-enabled interfaces. In many operational networks, OSPF runs over multiple links and in multi-tenant or misconfigured environments an attacker may be able to inject crafted LSAs. Even if debug-level dumping is not normally enabled, vendor images or custom builds could have the path reachable — a reality that increases blast radius in heterogeneous estates.
- Vendor packaging timelines vary. Some distributions deferred fixes pending backport testing; others already shipped updates. This means that system administrators cannot rely solely on upstream availability — distribution and appliance vendors must be checked for their specific remediation schedules.
- Public claims of available PoCs are mixed. Third-party aggregators listing PoCs may include code snippets that are incomplete, lab-only, or unsafe to run. Until a vetted PoC is published and verified by multiple independent parties, security teams should base response priorities on the presence of the vulnerability and the exposure of assets, not on sensational reporting.
Unverified or ambiguous elements to watch
- Some feeds or vendors report different CVSS or exploitability scores (reflecting different assumptions about default attack surface and diagnostics enabled). Where scores diverge, examine vendor notes carefully to reconcile assumptions about whether the vulnerable code path requires diagnostic flags or is reachable in normal operation. Flag these discrepancies and document which one applies to your environment.
Conclusion — prioritized action plan
- Treat CVE-2025-61102 and the related FRRouting OSPF NULL-pointer flaws as high-priority availability risks for environments that run FRR versions v4.0 through v10.4.1, especially where OSPF adjacencies or diagnostic packet dumps are enabled.
- Immediate steps: audit FRR versions in your estate, disable verbose OSPF packet debugging in production, and apply vendor/maintainer patches or the upstream fix as soon as feasible. Use control-plane filtering to mitigate exposure while you stage updates, and monitor ospfd behavior closely for crashes or OSPF traffic anomalies.
- Maintain conservative skepticism about unverified PoC claims and prioritize remediation based on asset exposure and vendor guidance. Keep configuration hygiene — limiting who can form OSPF adjacencies and removing unnecessary diagnostic verbosity — as a durable defense-in-depth practice against similar parsing-related DoS risks in routing daemons.
This is a practical, operationally urgent vulnerability for network operators and platform teams: the technical fix is straightforward, but the real-world challenge lies in quickly identifying affected instances across diverse distributions and appliance images — and in applying fixes without disrupting production routing.
Source: MSRC
Security Update Guide - Microsoft Security Response Center