Look up another CVE · open CVE-2026-98364 in the interactive tracker
CVE-2026-98364
xfrm: hold net_device reference under RCU in bundle creation
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-98364 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| 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
xfrm_bundle_create() and xfrm_create_dummy_bundle() read dst->dev into a local pointer without taking a device reference, then pass it to xfrm_fill_dst(). A concurrent RTM_DELLINK replaces dst->dev via dst_dev_put() and frees the old net_device, causing a use-after-free when xfrm6_fill_dst() later dereferences the stale dev pointer. BUG: KASAN: slab-use-after-free in xfrm6_fill_dst+0x82c/0x860 (net/ipv6/xfrm6_policy.c:86 netdev_hold()) Read of size 8 at addr ffff8880142fe588 by task exploit/153 Call Trace: xfrm6_fill_dst+0x82c/0x860 xfrm_resolve_and_create_bundle+0x21d4/0x2bd0 xfrm_lookup_with_ifid+0x485/0x1640 ip6_dst_lookup_flow+0x19b/0x1e0 udpv6_sendmsg+0x1443/0x2dd0 Fix this by reading dst->dev via dst_dev_rcu() and keeping the RCU read-side critical section active until xfrm_fill_dst() has taken the required device references.
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_policy.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.12%, higher than 1.7% 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 |
|---|---|---|
| 2.6.25 | 7.2.8 | 8d85d6bc9c46 |
| 2.6.25 | 7.3 | 9fa903b24b1f |
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
- Both sides of the race are local syscalls: sendmsg() (udpv6_sendmsg->ip6_dst_lookup_flow->xfrm_lookup_with_ifid->xfrm_bundle_create) and an RTM_DELLINK rtnetlink request that frees the net_device. A remote peer cannot delete the link, so the network cannot cause the freed state.
- AC:LAttack complexity, low
- The attacker controls both sides of the race: they repeatedly send through an xfrm-policy-matched route while deleting the link in a loop. The window between reading dst->dev and netdev_hold() in xfrm_fill_dst() is short, but the attacker can retry as often as needed.
- PR:LPrivileges required, low
- xfrm_user_rcv_msg only checks netlink_net_capable(CAP_NET_ADMIN), and RTM_DELLINK is also checked per namespace. An unprivileged user with unshare -Urn can create a device, install the XFRM policy and state, and delete the device inside their own network namespace.
- UI:NUser interaction, none
- No victim action is needed: the attacker sets up the namespace, the xfrm configuration, the sending socket and the link deletion entirely on their own.
- S:UScope, unchanged
- The use-after-free is inside the kernel's own networking code and the impact stays within the kernel's security authority; no VM or IOMMU boundary is crossed.
- C:HConfidentiality impact, high
- xfrm6_fill_dst() reads dev->ip6_ptr from the freed net_device through in6_dev_get() and stores the stale dev in a new dst. A reclaimed object controls those values, which can be used to disclose kernel memory.
- I:HIntegrity impact, high
- netdev_hold() increments a refcount inside the freed net_device, and in6_dev_get() increments a refcount on a pointer taken from the reclaimed object. Both are writes into attacker-reclaimable slab memory, usable to corrupt kernel data and hijack control flow.
- A:HAvailability impact, high
- KASAN reports a slab-use-after-free in xfrm6_fill_dst(). On production kernels the stale dev stays attached to the new xfrm dst and is dereferenced later, which leads to an oops or panic.