CVE-2025-68241: ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe
In the Linux kernel, the following vulnerability has been resolved:
ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe
The sit driver's packet transmission path calls: sit_tunnel_xmit() ->
update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called
to delete entries exceeding FNHE_RECLAIM_DEPTH+random.
The race window is between fnhe_remove_oldest() selecting fnheX for
deletion and the subsequent kfree_rcu(). During this time, the
concurrent path's __mkroute_output() -> find_exception() can fetch the
soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a
new dst using a dst_hold(). When the original fnheX is freed via RCU,
the dst reference remains permanently leaked.
CPU 0 CPU 1
__mkroute_output()
find_exception() [fnheX]
update_or_create_fnhe()
fnhe_remove_oldest() [fnheX]
rt_bind_exception() [bind dst]
RCU callback [fnheX freed, dst leak]
This issue manifests as a device reference count leak and a warning in
dmesg when unregistering the net device:
unregister_netdevice: waiting for sitX to become free. Usage count = N
Ido Schimmel provided the simple test validation method [1].
The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().
Since rt_bind_exception() checks this field, setting it to zero prevents
the stale fnhe from being reused and bound to a new dst just before it
is freed.
[1]
ip netns add ns1
ip -n ns1 link set dev lo up
ip -n ns1 address add 192.0.2.1/32 dev lo
ip -n ns1 link add name dummy1 up type dummy
ip -n ns1 route add 192.0.2.2/32 dev dummy1
ip -n ns1 link add name gretap1 up arp off type gretap \
local 192.0.2.1 remote 192.0.2.2
ip -n ns1 route add 198.51.0.0/16 dev gretap1
taskset -c 0 ip netns exec ns1 mausezahn gretap1 \
-A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &
taskset -c 2 ip netns exec ns1 mausezahn gretap1 \
-A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &
sleep 10
ip netns pids ns1 | xargs kill
ip netns del ns1
Security readout for executives and security teams
Plain-English summary
A Linux IPv4 routing race can permanently leak network-device references during tunnel-related traffic. Affected systems may fail to remove a network interface and emit repeated waiting warnings, disrupting network cleanup and availability. The supplied CVSS score is 7.5, with no indicated confidentiality or integrity impact.
Executive priority
Treat as a high-priority availability issue for tunnel-heavy hosts, network appliances, and infrastructure where interface teardown reliability matters. Patch through normal emergency kernel processes after compatibility testing. Lower the priority for systems demonstrably lacking the affected code path or already carrying a vendor backport.
Technical view
A stale fib next-hop exception can be selected for deletion while another CPU finds and rebinds it to a new destination entry. RCU later frees the exception but leaves the destination reference held. The kernel fix clears fnhe_daddr before flushing routes, causing rt_bind_exception() to reject the stale entry.
Likely exposure
Exposure is most plausible on affected Linux kernels using relevant IPv4 tunnel and routing paths under concurrent traffic. The bundle lists several affected kernel versions, but distribution kernels may backport fixes without changing their headline version; confirm using vendor build and patch metadata.
Exploitation context
The CVSS vector describes network-reachable, unauthenticated triggering with low complexity and high availability impact. However, the bundle marks KEV false and provides no evidence of active exploitation, public weaponization, or reliable remote exploitation outside controlled validation.
Researcher notes
The reported failure is a reference leak, not memory corruption or data disclosure. The race spans fnhe_remove_oldest(), find_exception(), rt_bind_exception(), and deferred RCU freeing. Exact real-world reachability depends on tunnel configuration, routing state, concurrency, and vendor kernel backports; the supplied evidence does not establish exploitation in the wild.
Mitigation direction
Upgrade to a vendor-supported kernel containing the applicable upstream stable fix.
Check distribution advisories and build metadata because vendors may backport the patch.
Prioritize systems using IPv4 tunnels or frequently creating and removing network interfaces.
Where immediate patching is impossible, reduce unnecessary exposure of affected tunnel paths.
Validation and detection
Inventory running kernel builds and identify systems using IPv4 tunnel interfaces.
Confirm the installed build includes the applicable stable fix or vendor backport.
Review kernel logs for unregister_netdevice waiting warnings involving tunnel devices.
Regression-test tunnel interface teardown under controlled concurrent traffic after patching.
Verify affected interfaces unregister normally and reference counts do not remain elevated.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-68241 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.