Look up another CVE · open CVE-2026-98369 in the interactive tracker
CVE-2026-98369
xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject()
Published 2026-10-06 (13 days ago) by the Linux kernel CNA. Subsystem net/xfrm. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-98369 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6568-1 · 2026-10-16 · text | 6.12.113-1 | Update the kernel and reboot. DSA-6568-1 shipped the fix on 2026-10-16, in 6.12.113-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.8-1 | Update the kernel and reboot. Fixed in 7.2.8-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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().
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/xfrm/xfrm_input.c
- What this is
- NETWORKING [IPSEC]MAINTAINERS section matched on net/xfrm/ · netdev@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_XFRM /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_XFRM
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-10-06 (13 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.15%, higher than 3.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/xfrm
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.15.75 | 5.15.222 | 41e47f1664be |
| 6.1 | 6.1.189 | 6601d91a8576 |
| 6.1 | 6.6.158 | 0cda8273265d |
| 6.1 | 6.12.112 | 68a317b4aec8 |
| 6.1 | 6.18.54 | 6eb3b071be8e |
| 6.1 | 7.2.8 | 664fc0941df7 |
| 6.1 | 7.3 | d2f5082f9e84 |
| 5.19.17 | 0 | 0 |
| 6.0.3 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DSA-6568-1 | 2026-10-16 | trixie 6.12.113-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The use-after-free happens only when a queued packet's net_device or noref dst is freed before xfrm_trans_reinject() runs. A remote ESP peer sends the packet but cannot unregister the device or change routes, so the attacker who controls the whole race is local: they create the netns, veth and XFRM SA through xfrm_user netlink.
- AC:LAttack complexity, low
- The attacker does both sides of the race. They send ESP transport-mode packets that xfrm4_transport_finish/xfrm6_transport_finish queue through xfrm_trans_queue(), then delete the veth or route while the workqueue is still behind. Flooding the queue up to max_backlog widens the window.
- PR:LPrivileges required, low
- xfrm_user_rcv_msg checks netlink_net_capable(CAP_NET_ADMIN), which an unprivileged user gets in a new user and network namespace (unshare -Urn). That lets them create the SA, the veth devices and the routes the trigger needs.
- UI:NUser interaction, none
- No victim action is needed. The attacker sets up the namespace, sends the packets and tears down the device or route themselves.
- S:UScope, unchanged
- The freed net_device, dst_entry and RCU-protected route data are kernel memory, and the impact stays within the kernel's own security authority.
- C:HConfidentiality impact, high
- ip6_rcv_finish and dst_input in xfrm_trans_reinject() read a freed skb->dev or noref dst_entry with no reference and no RCU lock. If an attacker reclaims that memory, these use-after-free reads can leak kernel memory.
- I:HIntegrity impact, high
- The freed dst_entry holds an input function pointer that dst_input() calls, and net_device is full of ops pointers. Reclaiming either object with attacker-controlled data gives a path to hijacking control flow.
- A:HAvailability impact, high
- A use-after-free of the net_device or dst in the xfrm_trans_reinject worker crashes the kernel, and syzbot hit the missing-RCU path in ip6_pkt_drop. The attacker can trigger it repeatedly.