CVE-2026-98369

In the Linux kernel, the following vulnerability has been resolved:

xfrm: add missing rcu read lock(), skb dst force() and dev hold() for xfrm trans reinject()

syzbot reported a suspicious RCU usage warning in ip6 pkt drop():

WARNING: suspicious RCU usage in ip6 pkt drop include/net/addrconf.h:389 suspicious rcu dereference check() usage!

Call Trace: in6 dev get safely include/net/addrconf.h:389 [inline] ip6 pkt drop+0x596/0x610 net/ipv6/route.c:4620 ip6 pkt discard+0x1c/0x30 net/ipv6/route.c:4651 xfrm trans reinject+0x324/0x630 net/xfrm/xfrm input.c:806 process one work kernel/workqueue.c:3322 [inline] process scheduled works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker thread+0xa47/0xfb0 kernel/workqueue.c:3486

When commit 4f4920669d21 ("xfrm: Reinject transport-mode packets through workqueue") converted xfrm trans reinject from a tasklet to a workqueue, the reinjection loop ceased running in softirq context. Workqueue workers run in process context where local bh disable() does not enter an RCU read-side critical section under CONFIG PREEMPT RCU.

Because finish callbacks (such as ip6 rcv finish) expect to run under an RCU read lock (performing route lookups, l3mdev lookups, and accessing RCU-protected data structures), invoking them in workqueue context without rcu read lock() triggers RCU lockdep warnings.

Furthermore, packets queued to the workqueue via xfrm trans queue net() may carry non-refcounted (noref) dst entries (e.g. from ip route input noref). Additionally, on netdevice unregistration, dst dev put() replaces dst->dev with blackhole netdev, so dst entries do not keep skb->dev alive while queued in the workqueue.

Fix these issues by: