CVE-2026-46116

Undergoing Analysis Undergoing Analysis - In Progress

Use-After-Free in Linux Kernel XFRM Subsystem

Publication date: 2026-05-28

Last updated on: 2026-07-07

Assigner: kernel.org

Description

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

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-05-28

Last Modified

2026-07-07

Generated

2026-07-08

AI Q&A

2026-05-28

EPSS Evaluated

2026-07-06

NVD

CVE-2026-46116

EUVD

EUVD-2026-32875

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	From 6.13 (inc) to 6.18.30 (exc)
linux	linux_kernel	From 6.19 (inc) to 7.0.7 (exc)
linux	linux_kernel	From 6.7 (inc) to 6.12.88 (exc)
linux	linux_kernel	From 6.2 (inc) to 6.6.140 (exc)
linux	linux_kernel	From 5.16 (inc) to 6.1.176 (exc)
linux	linux_kernel	From 2.6.19 (inc) to 5.15.210 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-763	The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.
CWE-416	The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Attack-Flow Graph

Executive Summary

This vulnerability exists in the Linux kernel's xfrm subsystem, specifically in the __xfrm_state_delete() function. It involves a slab-use-after-free issue triggered by improper handling of linked list deletions (unhashing) of xfrm_state objects. The function uses value-based predicates to decide whether to remove elements from hash lists, which can lead to inconsistent states and multiple deletions of the same object. This causes memory corruption, such as writing through poisoned list pointers, leading to potential crashes or undefined behavior.

The fix involves using safer list deletion functions (hlist_del_init_rcu()) that make repeated deletions no-ops and checking the actual list state with hlist_unhashed() instead of relying on mutable scalar fields. This defensive change prevents the use-after-free and out-of-bounds writes observed during testing with the syzkaller fuzzer.

Impact Analysis

This vulnerability can lead to memory corruption in the Linux kernel, specifically use-after-free and out-of-bounds writes within the xfrm_state lifecycle. Such memory corruption can cause system instability, crashes, or potentially allow an attacker to execute arbitrary code or escalate privileges if exploited.

Since the issue occurs in the kernel's networking subsystem related to IPsec (xfrm), it could be triggered remotely or locally under certain conditions, impacting the reliability and security of systems running vulnerable Linux kernel versions.

Detection Guidance

This vulnerability involves a slab-use-after-free in the Linux kernel's xfrm_state lifecycle, which can be detected using Kernel Address Sanitizer (KASAN) with specific configurations.

Detection typically requires running the kernel with KASAN enabled (e.g., KASAN_GENERIC and KASAN_INLINE) and using a fuzzer like syzkaller to exercise the vulnerable code paths.

There are no specific commands provided in the context to detect this vulnerability directly on a system or network.

Mitigation Strategies

The vulnerability has been resolved by applying a defensive patch to the Linux kernel that changes how xfrm_state lists are unhashed to prevent use-after-free conditions.

Immediate mitigation involves updating the Linux kernel to a version that includes this patch (for example, version 6.12.47 with the fix applied or later).

Running the patched kernel prevents the slab-use-after-free by using safer list deletion functions and proper state checks.

Hi! I’m here to help you understand CVE-2026-46116. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70