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
Produtos afetados
Linux · LinuxQuer saber se a sua infraestrutura está exposta a isto?
Falar com a TrueHacking →Referências
https://git.kernel.org/stable/c/041ab9ca6e80d8f792bb69df28ebf1ef39c06af8https://git.kernel.org/stable/c/0fd16ed6dc331636fb2a874c42d2f7d3156f7ff0https://git.kernel.org/stable/c/298f1e0694ab4edb6092d66efed93c4554e6ced1https://git.kernel.org/stable/c/4b7210da22429765d19460d38c30eeca72656282https://git.kernel.org/stable/c/69d35c12168f9c59b159ae566f77dfad9f96d7cahttps://git.kernel.org/stable/c/ac1499fcd40fe06479e9b933347b837ccabc2a40https://git.kernel.org/stable/c/b84f083f50ecc736a95091691339a1b363962f0ehttps://git.kernel.org/stable/c/b8a44407bdaf2f0c5505cc7d9fc7d8da90cf9a94