CVE-2026-97974: ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings()
In the Linux kernel, the following vulnerability has been resolved:
ipv6: null-check fib6node before accessing in ip6delrtsiblings()
syzbot reported a null-ptr-deref in ip6delrtsiblings() [0].
The stack trace hinted towards a null dereference of rt->fib6node when fn->leaf is accessed in ip6delrtsiblings(). With RTNLFLAGDOITUNLOCKED set, inet6rtmdelroute() operations run concurrently without acquiring the RTNL lock. In ip6routedel(), the route lookup happens under rcureadlock() without acquiring table->tb6lock.
Between ip6routedel() looking up the route and ip6delrtsiblings() acquiring table->tb6lock, another thread can modify the routing table. For example, when an ECMP route is replaced via RTMNEWROUTE with NLMFREPLACE, fib6addrt2node() unlinks all old siblings and sets iter->fib6node = NULL. A reproducer was found that triggers this [1].
Add a check to ensure rt->fib6node is non-null before accessing it.
[0] KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:ip6delrtsiblings+0x31e/0x7c0 net/ipv6/route.c:4056 Call Trace: <TASK> ip6routedel+0x1054/0x1110 net/ipv6/route.c:4232 inet6rtmdelroute+0x5d7/0x6d0 net/ipv6/route.c:5669 rtnetlinkrcvmsg+0x802/0xc00 net/core/rtnetlink.c:7132 netlinkrcvskb+0x226/0x4a0 net/netlink/afnetlink.c:2556 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0x7f5/0x990 net/netlink/afnetlink.c:1345 netlinksendmsg+0x813/0xb40 net/netlink/afnetlink.c:1900 socksendmsgnosec+0x13a/0x180 net/socket.c:800 socksendmsg net/socket.c:815 [inline] syssendmsg+0x565/0x870 net/socket.c:2713 syssendmsg+0x2a5/0x360 net/socket.c:2767 syssendmsg net/socket.c:2799 [inline] dosyssendmsg net/socket.c:2804 [inline] sesyssendmsg net/socket.c:2802 [inline] x64syssendmsg+0x1b7/0x290 net/socket.c:2802 dosyscallx64 arch/x86/entry/syscall64.c:61 [inline] dosyscall64+0x166/0x520 arch/x86/entry/syscall64.c:84 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
[1] https://gist.github.com/NamanGulati/0766a1159b6ca61928faaf87425ff899
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the null-pointer dereference?
The issue requires concurrent IPv6 route operations: a route deletion running without the RTNL lock and a concurrent routing-table modification. One described trigger is replacing an ECMP route through RTM_NEWROUTE with NLM_F_REPLACE while the deletion path is between route lookup and acquisition of the table lock.
What is the practical impact if the race occurs?
The affected deletion path can dereference a NULL rt->fib6_node in __ip6_del_rt_siblings(), resulting in a kernel null-pointer dereference. The provided report identifies this as a KASAN-detected crash condition.
How can I determine whether a system is exposed to this condition?
Exposure depends on whether the kernel includes the fix that checks rt->fib6_node before it is accessed in __ip6_del_rt_siblings(). Systems performing concurrent IPv6 route deletion and ECMP route replacement are the relevant operational scenario described.