CVE-2026-74656: ipv4: fix use-after-free in fib_nhc_update_mtu()
In the Linux kernel, the following vulnerability has been resolved:
ipv4: fix use-after-free in fibnhcupdatemtu()
fibnhcupdatemtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcudereferenceprotected() with a constant true condition without holding fnhelock.
The following interleaving can therefore occur:
CPU 0 CPU 1 fibnhcupdatemtu() updateorcreatefnhe() load fnhe spinlockbh(&fnhelock) fnheremoveoldest() unlink fnhe kfreercu(fnhe, rcu) <quiescent state> access fnhe after grace period
KASAN reported:
BUG: KASAN: slab-use-after-free in fibnhcupdatemtu+0x3df/0x410 Read of size 8 at addr ffff888107d49000 by task poc/90 Call Trace: fibnhcupdatemtu+0x3df/0x410 fibsyncmtu+0x7a/0xd0 fibnetdevevent+0x229/0x3f0 netifsetmtuext+0x33a/0x570 devsetmtu+0x88/0x120
The same walk updates fnhepmtu and fnhemtulocked. These fields form a pair and other writers serialize them with fnhelock. RCU alone prevents reclamation, but would still allow concurrent writers to leave a mixed pair.
Walk the table under RCU and acquire fnhelock only while updating each exception. RCU keeps the current entry alive while the short critical section serializes its paired PMTU fields. This avoids holding the global lock while scanning all 2048 buckets for every nexthop.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.152.1-1
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
The race requires fib_nhc_update_mtu() to walk nexthop exceptions while another CPU updates PMTU exceptions and removes an exception entry. The described path includes an MTU change event and concurrent update_or_create_fnhe() activity.
What is the impact if the race occurs?
A freed nexthop exception entry can be accessed after its RCU grace period, producing a slab use-after-free. The report shows KASAN detecting an 8-byte read in fib_nhc_update_mtu().
What synchronization does the fix add?
The corrected approach walks the exception table under RCU and takes fnhe_lock while updating each exception. This both prevents use of reclaimed entries and serializes updates to the paired fnhe_pmtu and fnhe_mtu_locked fields.