CVE-2026-74562 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
nexthop: take nh->lock for f6i_list walks in replace check and notify
fib6_check_nh_list() and __nexthop_replace_notify() walk nh->f6i_list during an RTNL-serialized nexthop replace without holding nh->lock. IPv6 RTM_NEWROUTE/RTM_DELROUTE run without RTNL and mutate that list under nh->lock (fib6_add_rt2node_nh(), fib6_purge_rt()), so both walks race a concurrent route delete that unlinks and frees a fib6_info:
BUG: KASAN: slab-use-after-free in rt6_fill_node.isra.0 (net/ipv6/route.c:5799) Read of size 4 at addr ffff888014607e64 by task exploit/143 rt6_fill_node.isra.0 (net/ipv6/route.c:5799) fib6_rt_update (net/ipv6/route.c:6412) __nexthop_replace_notify (net/ipv4/nexthop.c:2542) rtm_new_nexthop (net/ipv4/nexthop.c:2554) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)
BUG: KASAN: slab-use-after-free in fib6_check_nh_list (net/ipv4/nexthop.c:1605) Read of size 8 at addr ffff888014a7d068 by task exploit/142 fib6_check_nh_list (net/ipv4/nexthop.c:1605) rtm_new_nexthop (net/ipv4/nexthop.c:2575) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076)
Both walks only read the entries and take no tb6_lock, so protect them with nh->lock; fib6_rt_update() uses gfp_any(), which returns GFP_ATOMIC under the lock.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists in the linux kernel's ipv6 routing implementation where concurrent access to nexthop data structures creates a race condition leading to use-after-free errors. The issue occurs during nexthop replacement operations when functions fib6_check_nh_list() and __nexthop_replace_notify() traverse the nh->f6i_list without acquiring the nh->lock mutex. These functions are called during RTM_NEWROUTE/RTM_DELROUTE operations that execute outside of the RTNL serialization context, meaning they can run concurrently with route modification operations that mutate the same list structure under nh->lock protection.
The race condition manifests when a route deletion operation calls fib6_purge_rt() or fib6_add_rt2node_nh() which unlink and free fib6_info entries from the nh->f6i_list while the aforementioned functions are simultaneously reading from this same list. This creates a scenario where memory that has been freed is still being accessed, resulting in kernel memory corruption and potential privilege escalation. The kernel address sanitizer (KASAN) detects these violations with specific error messages indicating slab-use-after-free conditions at precise locations within the routing code.
The vulnerability directly maps to CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer and CWE-367 Time-of-Check Time-of-Use (TOCTOU) Race Condition, as the functions perform list traversal without proper locking mechanisms. From an ATT&CK perspective, this represents a privilege escalation vector through kernel memory corruption that could potentially allow attackers to execute arbitrary code with kernel privileges. The use of GFP_ATOMIC allocation within fib6_rt_update() under lock context further demonstrates how the race condition can lead to unpredictable kernel behavior.
The fix requires protecting both fib6_check_nh_list() and __nexthop_replace_notify() functions with nh->lock acquisition during their list traversal operations, ensuring exclusive access to the nh->f6i_list during these critical sections. This approach prevents concurrent modifications while maintaining read consistency, effectively eliminating the race condition that leads to use-after-free errors and memory corruption throughout the ipv6 routing subsystem. The solution follows standard kernel programming practices for protecting shared data structures through proper locking mechanisms as recommended in the Linux kernel documentation and security guidelines.