Look up another CVE · open CVE-2026-68420 in the interactive tracker

CVE-2026-68420

xfrm: reject optional IPTFS templates in outbound policies

7.1 EPSS 0.1% AV:L

Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem net/xfrm. Debian urgency: unimportant.

What to do, per Debian release

Debian's own status for CVE-2026-68420 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	not affected	6.1.190-1	Nothing to do. bookworm never shipped the vulnerable code.
Debian 13trixie	not affected	6.12.113-1	Nothing to do. trixie never shipped the vulnerable code.
Debian 14forky	fixed	7.1.6-1	Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.6-1	Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

syzbot reported a stack-out-of-bounds read in xfrm_state_find() which flows from xfrm_tmpl_resolve_one(). Commit 3d776e31c841 ("xfrm: Reject optional tunnel/BEET mode templates in outbound policies") disallowed optional tunnel and BEET in outbound policies to prevent this. Later when IPTFS added, it was not covered by that fix and can still trigger the out-of-bounds read; Extend the check to disallow optional IPTFS in outbound policies as well. IPTFS should be identical to tunnel mode. IN and FWD policies are not affected: xfrm_tmpl_resolve_one() is only reachable via the outbound path. Reproducer, before: ip link add dummy0 type dummy ip link set dummy0 up ip addr add 10.1.1.1/24 dev dummy0 ip xfrm policy add src 10.1.1.1/32 dst 10.1.1.2/32 dir out tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 1 mode iptfs level use tmpl src fc00::dead:1 dst fc00::dead:2 proto esp reqid 2 mode transport ping -W 1 -c 1 10.1.1.2 PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data. [ 64.168420] ================================================================== [ 64.169977] BUG: KASAN: stack-out-of-bounds in __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] Read of size 4 at addr ffff88800e1ffd20 by task ping/2844 [ 64.169977] CPU: 2 UID: 0 PID: 2844 Comm: ping Not tainted 7.1.0-rc7-00180-geb23b588430a #98 PREEMPT(full) [ 64.169977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 64.169977] Call Trace: [ 64.169977] <TASK> [ 64.169977] dump_stack_lvl+0x47/0x70 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] print_report+0x152/0x4b0 [ 64.169977] ? ksys_mmap_pgoff+0x6d/0xa0 [ 64.169977] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 64.169977] ? rcu_read_unlock_sched+0xa/0x20 [ 64.169977] ? __virt_addr_valid+0x21b/0x230 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] kasan_report+0xa8/0xd0 [ 64.169977] ? __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm6_addr_hash+0x11e/0x170 [ 64.169977] __xfrm_dst_hash+0x24/0xc0 [ 64.169977] xfrm_state_find+0xa2d/0x2f90 [ 64.169977] ? __pfx_xfrm_state_find+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] ? __pfx_ftrace_graph_ret_addr+0x10/0x10 [ 64.169977] xfrm_tmpl_resolve_one+0x210/0x570 [ 64.169977] ? __pfx_xfrm_tmpl_resolve_one+0x10/0x10 [ 64.169977] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 64.169977] ? kernel_text_address+0x5b/0x80 [ 64.169977] ? __kernel_text_address+0xe/0x30 [ 64.169977] ? unwind_get_return_address+0x5e/0x90 [ 64.169977] ? arch_stack_walk+0x8c/0xe0 [ 64.169977] xfrm_tmpl_resolve+0x130/0x200 [ 64.169977] ? __pfx_xfrm_tmpl_resolve+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_inexact_lookup_rcu+0x10/0x10 [ 64.169977] ? __refcount_add_not_zero.constprop.0+0xb2/0x110 [ 64.169977] ? __pfx___refcount_add_not_zero.constprop.0+0x10/0x10 [ 64.169977] xfrm_resolve_and_create_bundle+0xd5/0x310 [ 64.169977] ? __pfx_xfrm_resolve_and_create_bundle+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] ? __pfx_xfrm_policy_lookup_bytype+0x10/0x10 [ 64.169977] xfrm_lookup_with_ifid+0x3d8/0xb80 [ 64.169977] ? __pfx_xfrm_lookup_with_ifid+0x10/0x10 [ 64.169977] ? ip_route_output_key_hash+0xc6/0x110 [ 64.169977] ? kasan_save_track+0x10/0x30 [ 64.169977] xfrm_lookup_route+0x18/0xe0 [ 64.169977] ip4_datagram_release_cb+0x4c9/0x530 [ 64.169977] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 64.169977] ? do_raw_spin_lock+0x71/0xc0 [ 64.169977] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 64.169977] release_sock+0xb0/0x170 [ 64.169977] udp_connect+0x43/0x50 [ 64.169977] __sys_connect+0xa6/0x100 [ 64.169977] ? alloc_fd+0x2e9/0x300 [ 64.169977] ? __pfx___sys_connect+0x10/0x10 [ 64.169977] ? preempt_latency ---truncated---

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_user.c

What this is: NETWORKING [IPSEC]MAINTAINERS section matched on net/xfrm/ · netdev@vger.kernel.org · Maintained
Kernel module: xfrm_user

Check it on the machine

grep -wE 'CONFIG_XFRM|CONFIG_XFRM_USER' /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.

lsmod | grep -w xfrm_user

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

bookworm, trixie, forky, sidm

m: a loadable module on every flavour - check lsmod, can be blacklisted

Build switches: CONFIG_XFRM, CONFIG_XFRM_USER
Reads as: all on means the file is compiled; any one off means it is not.

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

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-08-10 (2 months ago)source
CVSS: 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.11%, higher than 1.5% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: unimportantsource
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
6.14	6.18.42	d7fc6f351c47
6.14	7.1.6	9333f4b6f448
6.14	7.2	ea528f18231e

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 attacker must install an XFRM policy over the AF_KEY/XFRM netlink socket and then originate local traffic (connect()/sendto()) matching that policy, so the entire path requires local access to the machine; no remote packet reaches this code.
AC:LAttack complexity, low: The reproducer is deterministic — add one outbound policy with an optional IPTFS template plus a following transport-mode template of a different family, then send one packet; no race, no memory-layout dependence, and CONFIG_XFRM is enabled on all mainstream distros.
PR:LPrivileges required, low: xfrm_user_rcv_msg() checks netlink_net_capable(CAP_NET_ADMIN), which resolves to ns_capable(net->user_ns, CAP_NET_ADMIN); an unprivileged user obtains this with "unshare -Urn" and can create the dummy device, the policy, and the triggering traffic entirely inside that namespace.
UI:NUser interaction, none: The attacker performs every step — policy insertion and packet transmission — with no action by any other user or administrator.
S:UScope, unchanged: The out-of-bounds read stays within the kernel's own stack and the affected resources are managed by the same kernel security authority; no VM, IOMMU, or sandbox boundary is crossed.
C:HConfidentiality impact, high: __xfrm6_addr_hash() reads 16 bytes from a 4-byte on-stack IPv4 address, exposing adjacent kernel stack contents; with zeroed template addresses xfrm_init_tempstate() copies those bytes into the acquire state, which is broadcast to userspace via XFRM_MSG_ACQUIRE, leaking kernel stack data (potentially pointers usable for KASLR defeat).
I:NIntegrity impact, none: The defect is purely a read of out-of-bounds stack memory; no kernel memory is written out of bounds and no control-flow or data structure is corrupted by the attacker.
A:HAvailability impact, high: The invalid access is a KASAN-detected stack out-of-bounds read that taints the kernel and terminates the machine on kernels built with KASAN or panic_on_warn, and the bogus state derived from garbage addresses can be re-triggered at will by an unprivileged user.