CVE-2026-98364: xfrm: hold net_device reference under RCU in bundle creation
In the Linux kernel, the following vulnerability has been resolved:
xfrm: hold netdevice reference under RCU in bundle creation
xfrmbundlecreate() and xfrmcreatedummybundle() read dst->dev into a local pointer without taking a device reference, then pass it to xfrmfilldst(). A concurrent RTMDELLINK replaces dst->dev via dstdevput() and frees the old netdevice, causing a use-after-free when xfrm6filldst() later dereferences the stale dev pointer.
BUG: KASAN: slab-use-after-free in xfrm6filldst+0x82c/0x860 (net/ipv6/xfrm6policy.c:86 netdevhold()) Read of size 8 at addr ffff8880142fe588 by task exploit/153 Call Trace: xfrm6filldst+0x82c/0x860 xfrmresolveandcreatebundle+0x21d4/0x2bd0 xfrmlookupwithifid+0x485/0x1640 ip6dstlookupflow+0x19b/0x1e0 udpv6sendmsg+0x1443/0x2dd0
Fix this by reading dst->dev via dstdevrcu() and keeping the RCU read-side critical section active until xfrmfilldst() has taken the required device references.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
The issue requires a race between XFRM bundle creation and a concurrent RTM_DELLINK operation. The link deletion can replace dst->dev and free the prior net_device while xfrm_fill_dst() later uses the stale pointer.
Which execution path is shown to reach the vulnerable dereference?
The reported call trace reaches xfrm6_fill_dst() through xfrm_resolve_and_create_bundle(), xfrm_lookup_with_ifid(), ip6_dst_lookup_flow(), and udpv6_sendmsg(). This indicates an IPv6 XFRM bundle-resolution path.
How can I identify whether this issue has occurred on a system?
The supplied report shows KASAN detecting a slab-use-after-free in xfrm6_fill_dst(), at net/ipv6/xfrm6_policy.c:86 during netdev_hold(). Kernel logs containing that function and a KASAN use-after-free report are evidence of the condition.