CVE-2026-98369xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject()
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
EPSS puts the chance of exploitation in the next 30 days at 0.15%, higher than 3% of scored CVEs.
Do this next
Free account, 1 product
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: 1. Calling skb_dst_force(skb) in xfrm_trans_queue_net() while still in the caller's RCU section to ensure dst is reference-counted before queuing. 2. Holding a reference on skb->dev via dev_hold()/dev_put() across workqueue deferral so skb->dev remains valid during finish() callback processing. 3. Acquiring rcu_read_lock() around the finish callback invocation loop in xfrm_trans_reinject().
- CVSS
- 7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- 0.15% (percentile 3)
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 7, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from 7d98b26684cb2390729525b341ea099f0badbe18 before 41e47f1664be86c91326f0afe0504a1162d00907; from 4f4920669d21e1060b7243e5118dc3b71ced1276 before 6601d91a85761f33351c71e04ec0bbd294ca07ce; 4f4920669d21e1060b7243e5118dc3b71ced1276 builds before 0cda8273265d30cac6423834fd7d4acb75f04fdb; from 4f4920669d21e1060b7243e5118dc3b71ced1276 before 68a317b4aec8ca1868a39d69e40f9e29baa4f40a; from 4f4920669d21e1060b7243e5118dc3b71ced1276 before 6eb3b071be8e260543c604550c54dac66e6b174b; from 4f4920669d21e1060b7243e5118dc3b71ced1276 before 664fc0941df7c1918b2cd4de6ee00469ba77d8e4; from 4f4920669d21e1060b7243e5118dc3b71ced1276 before d2f5082f9e84653fa1a9e8aebaaff23e688f5e19; f520075da484306bbb8425afd2c42404ba74816f; and 4 more ranges | CNA record |
References
- https://git.kernel.org/stable/c/41e47f1664be86c91326f0afe0504a1162d00907
- https://git.kernel.org/stable/c/6601d91a85761f33351c71e04ec0bbd294ca07ce
- https://git.kernel.org/stable/c/0cda8273265d30cac6423834fd7d4acb75f04fdb
- https://git.kernel.org/stable/c/68a317b4aec8ca1868a39d69e40f9e29baa4f40a
- https://git.kernel.org/stable/c/6eb3b071be8e260543c604550c54dac66e6b174b
- https://git.kernel.org/stable/c/664fc0941df7c1918b2cd4de6ee00469ba77d8e4
- https://git.kernel.org/stable/c/d2f5082f9e84653fa1a9e8aebaaff23e688f5e19
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.