CVE-2026-46116: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete
In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: if (x->km.seq) hlist_del_rcu(&x->byseq); if (x->id.spi) hlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle
HarborGuard Analysis
HarborGuard analysisSynopsis
A use-after-free vulnerability exists in the Linux kernel's XFRM (IPsec transform) subsystem, specifically in the __xfrm_state_delete() function. An attacker with a low-privilege local account can trigger the flaw on affected kernel versions, leading to memory corruption through inconsistent hash-list removal logic. Successful exploitation gives the attacker read access to arbitrary kernel memory, the ability to corrupt kernel data structures, and the ability to crash the system. A patched-image rebuild at the fix version is available on HarborGuard for environments running an affected kernel version.
HarborGuard Coverage
Detection of CVE-2026-46116 is available across every HarborGuard environment; the CVE is ingested from upstream feeds (including the Linux kernel security advisories and NVD) within minutes of publication and matched against customer images in registries and CI/CD pipelines, including custom-built images that bundle a vulnerable kernel version.
AvailableHarborGuard is capable of scoring this CVE at CVSS 7.8 HIGH and weighting that score against each customer environment's compliance policy to determine urgency. Triage routing is available to direct findings to the appropriate team inbox within each customer organization based on image ownership and policy configuration.
AvailableA patched-image rebuild at fix version 6.6.140 (and corresponding upstream commit references) becomes available on HarborGuard once the affected base image is identified in a customer's registry or pipeline. For customers who opt into auto-remediation, HarborGuard can perform the rebuild, run a regression test suite, and open a PR against affected workloads automatically.
AvailableExploit Conditions
- Network reachabilityNot required
The attacker needs an existing shell or process on the host; no network access is required to reach the vulnerable code path.
- AuthenticationRequired
Any low-privilege local account is sufficient to trigger the vulnerable XFRM state deletion path.
- Victim interactionNot required
No action from another user or process is needed; the attacker can trigger the bug entirely on their own.
- Attack complexityDetail
The exploit is reliable and does not depend on race conditions or specific memory layout; attack complexity is rated Low.
Blast Radius
- Reads arbitrary kernel memory, exposing sensitive data such as cryptographic key material held in xfrm_state objects.
- Corrupts kernel slab objects by writing through a poisoned list pointer, potentially hijacking control flow or escalating privileges.
- Crashes the affected host by inducing a kernel panic through the slab-use-after-free write, causing a denial of service for all workloads on that node.
- Destabilizes IPsec/VPN tunnel state, disrupting encrypted network connections managed by the XFRM subsystem.
How HarborGuard Handles This
Available on HarborGuard: detection of this CVE is matched against all images in connected registries and pipelines as soon as the advisory is ingested. For environments running an affected Linux kernel version, a patched-image rebuild targeting fix version 6.6.140 (or the relevant upstream commit) is available. For customers who opt into auto-remediation, HarborGuard can trigger a rebuild, execute a regression test run, and open a PR against affected workloads; median time from CVE publication to merged patch PR for high-severity issues is around 90 minutes in environments with auto-remediation enabled. Where compliance policy does not permit auto-remediation, HarborGuard surfaces the finding with CVSS 7.8 HIGH scoring and policy-weighted priority so the responsible team can act manually. Because this is a local-privilege flaw in the kernel's IPsec subsystem, customers may also consider applying network-policy controls that limit IPsec configuration capabilities to privileged workloads as a compensating control until patched images are deployed.
Metrics
- CVSS v3.1
- 7.8
- Severity
- HIGH
- Fixed in
- 0
- Affected Products
- 2
Fix available
- Linux / Linux< b4a53add2fa8f1b5aa17d4c5686c320785fab182 (from 7b4dc3600e4877178ba94c7fbf7e520421378aa6) · < 26edb0a3c99f9d958c212be68b21f1221614dcf0 (from 7b4dc3600e4877178ba94c7fbf7e520421378aa6) · < 4980162de555cb838f1a189ce7d2cbf5d2e7b050 (from 7b4dc3600e4877178ba94c7fbf7e520421378aa6) · < a2e2d08fb070fab4947447171f1c4e3ca5a188e5 (from 7b4dc3600e4877178ba94c7fbf7e520421378aa6) · < 14acf9652e5690de3c7486c6db5fb8dafd0a32a3 (from 7b4dc3600e4877178ba94c7fbf7e520421378aa6)
- Linux / Linux2.6.19Fixed in 0, 6.6.140, 6.12.88, 6.18.30, 7.0.7, 7.1-rc3
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H