CVE-2026-74561 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
nexthop: avoid unlocked f6i_list walk in nh_rt_cache_flush
nh_rt_cache_flush() walks nh->f6i_list during an RTNL-serialized nexthop replace without holding nh->lock, racing the unlocked IPv6 route add/delete that mutate the list under nh->lock and free fib6_info entries (nh_rt_cache_flush() is inlined into rtm_new_nexthop()):
BUG: KASAN: slab-use-after-free in nh_rt_cache_flush (net/ipv4/nexthop.c:2243) Read of size 8 at addr ffff888012953e18 by task exploit/146 nh_rt_cache_flush (net/ipv4/nexthop.c:2243) replace_nexthop (net/ipv4/nexthop.c:2610) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)
Unlike the other f6i_list walks, this one bumps each route's sernum via fib6_update_sernum_upto_root(), which needs tb6_lock; taking nh->lock around it would invert the established tb6_lock -> nh->lock order and deadlock. As the only purpose is to invalidate cached dsts, bump the IPv6 sernum for the whole netns with rt_genid_bump_ipv6() instead, mirroring the rt_cache_flush() already done for IPv4 just above.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists in the linux kernel's nexthop implementation where a race condition occurs during route cache flushing operations. The flaw manifests when nh_rt_cache_flush() function attempts to traverse the nh->f6i_list structure without holding the nh->lock mutex, while concurrent IPv6 route addition or deletion operations mutate the same list under protection of nh->lock. This creates a classic use-after-free scenario where the flush operation accesses memory that may have been freed by the concurrent mutation operations.
The technical root cause stems from improper locking hierarchy management within the kernel's networking subsystem. The nh_rt_cache_flush() function performs a specific operation that requires updating each route's sernum through fib6_update_sernum_upto_root(), which in turn requires acquiring tb6_lock. However, the existing code structure prevents taking nh->lock around this sernum update because doing so would create a lock inversion scenario where tb6_lock is acquired before nh->lock, potentially leading to deadlocks. This lock ordering constraint forces the function to access the f6i_list without proper synchronization.
The operational impact of this vulnerability extends beyond simple memory corruption, as it represents a security risk that could be exploited through carefully crafted network operations. Attackers could potentially trigger the race condition by simultaneously performing nexthop replacement operations alongside IPv6 route modifications, leading to system instability, kernel crashes, or in more sophisticated scenarios, potential privilege escalation. The KASAN report indicates a slab-use-after-free error occurring at net/ipv4/nexthop.c:2243, demonstrating the memory safety violation that occurs when freed memory is accessed.
The proposed fix addresses this issue by changing the approach to invalidate cached destinations. Instead of attempting to update individual route sernums through the problematic fib6_update_sernum_upto_root() function, the solution uses rt_genid_bump_ipv6() to bump the entire IPv6 serialization number for the network namespace. This approach mirrors the existing IPv4 implementation pattern that already handles similar cache invalidation scenarios correctly. The fix eliminates the race condition by avoiding the problematic lock ordering while maintaining the intended functionality of cache invalidation across all routes in the network namespace.
This vulnerability type maps to CWE-367: Time-of-Check Time-of-Use (TOCTOU) and CWE-129: Improper Validation of Array Index, as it involves improper synchronization during list traversal operations. From an ATT&CK perspective, this could be categorized under T1059.006: System Scripting and potentially T1499.004: Endpoint Denial of Service through kernel-level memory corruption that affects system availability. The fix demonstrates proper kernel security practices by ensuring lock ordering consistency and avoiding complex locking patterns that could introduce deadlocks while maintaining the intended cache coherency guarantees for network routing operations.