CVE-2026-98598: ipv6: Prevent rt6_insert_exception() for dying fib6_info.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Prevent rt6insertexception() for dying fib6info.
Before the cited commit, fib6nhflushexceptions() always set from->exceptionbucketflushed = 1 under rt6exceptionlock to prevent rt6insertexception() from inserting a new exception for a dying fib6info.
The flag was replaced with the FIB6EXCEPTIONBUCKETFLUSHED bit stored in nh->rt6iexceptionbucket.
The problem is that now the bit is only set when the bucket is not NULL and fib6nhflushexceptions() is called from fib6nhrelease() after fib6ref has already reached zero.
If rt6insertexception() is called while the target fib6info is being removed via fib6purgert(), a new exception could be created successfully because rt6flushexceptions() no longer sets the bit.
This creates a reference cycle between the fib6info and the exception route, leaking the fib6info, its nexthop device, and all per-CPU routes in fib6nh->rt6ipcpu, which stalls netdev unregistration.
[ 34.680602] unregisternetdevice: waiting for gre6 to become free. Usage count = 68 [ 44.920675] unregisternetdevice: waiting for gre6 to become free. Usage count = 68 [ 55.176582] unregisternetdevice: waiting for gre6 to become free. Usage count = 68
Let's call fib6droppcpufrom() before rt6flushexceptions(), to set fib6destroying before rt6exceptionlock, and check f6i->fib6destroying in rt6insertexception().
Note that FIB6EXCEPTIONBUCKETFLUSHED logic is dead and we can clean it up in net-next.
Affected Software
Event History
Frequently Asked Questions
What operational impact can this cause?
The flaw can create a reference cycle that leaks the affected fib6_info, its nexthop device, and associated per-CPU routes. This can stall network-device unregistration, with the kernel repeatedly waiting for a device to become free.
When does the leak occur?
It occurs if rt6_insert_exception() runs while the target fib6_info is being removed through fib6_purge_rt(). In that race, a new exception route can be inserted for a fib6_info that is being removed.
How can administrators identify a possible affected system?
A possible symptom is kernel log output during device removal stating that unregister_netdevice is waiting for a device to become free, along with a persistent usage count. The example provided shows this for a gre6 device.