CVE-2025-68241

What it actually does

Race condition in IPv4 route exception handling allows concurrent sit tunnel transmission and route lookup paths to bind a soon-to-be-freed fnhe entry to a new dst, leaking the dst reference count via RCU free without corresponding release.

Why it matters to the business

Kernel memory leaks accumulate under network load, producing device reference count warnings and potential hangs when unregistering network interfaces such as sit or gretap devices, increasing operational risk on systems that create or remove virtual network devices.

How an attack unfolds

An attacker or workload triggers concurrent packet transmission through sit/gretap tunnels while route cache reclamation occurs; fnhe_remove_oldest selects an entry for deletion while find_exception and rt_bind_exception on another CPU acquire and hold a dst reference, resulting in a permanent leak after the RCU callback frees the fnhe.

How to fix it

Upgrade the Linux kernel to version 5.4.302 or later (or the equivalent stable commit 69d35c12168f9c59b159ae566f77dfad9f96d7ca) that clears oldest->fnhe_daddr before fnhe_flush_routes to prevent reuse of stale entries; apply the matching fixed package versions for any downstream distributions such as Chainguard gitlab-pages-17.7.4-r0.

How to confirm the fix worked

Confirm the patch is present by checking kernel source for the fnhe_daddr zeroing change before fnhe_flush_routes; reproduce the provided netns test case under load and verify absence of unregister_netdevice warnings and leaked reference counts on interface deletion.

Typical attack path

1. Create sit or gretap tunnel interfaces and install routes that populate fnhe entries
2. Generate high-rate traffic that causes fnhe reclamation to exceed FNHE_RECLAIM_DEPTH
3. Simultaneously perform route lookups that invoke find_exception on the same fnhe
4. Allow RCU grace period to free the fnhe while the dst reference remains held
5. Observe reference count leak and unregister_netdevice warnings on interface teardown

How to detect it

Search kernel logs and dmesg for 'unregister_netdevice: waiting for .* to become free' messages; inspect net device usage counts via /proc/net/dev or ip link output after interface deletion under load; no remote exploitation artifacts are expected.

What your security team should do

• Prioritize kernel upgrades on systems using sit, gretap, or other tunnel devices that trigger fnhe reclamation
• Monitor dmesg for unregister_netdevice reference count warnings as an indicator of exposure
• Limit creation and teardown of virtual network devices in high-traffic environments until patched