CVE-2026-46116

What it actually does

This is a Linux kernel use-after-free flaw in the XFRM/IPsec state lifecycle. The vulnerable code deletes XFRM state hash-list entries based on mutable field values rather than actual list membership, and repeated or racing deletion paths can write through stale list pointers after an xfrm_state object has already been removed or freed. Triggering the bug can cause kernel memory corruption, including slab use-after-free and out-of-bounds write conditions in paths such as __xfrm_state_delete(), __xfrm_state_lookup(), xfrm_alloc_spi(), and __xfrm_state_insert(). Because the corruption occurs in kernel space, successful exploitation could allow a local attacker to crash the system or potentially escalate privileges and execute code with kernel-level privileges.

Why it matters to the business

Systems running affected Linux kernel versions may be vulnerable to local denial of service or local privilege escalation. The highest operational risk is on multi-user systems, container hosts, CI runners, shared development systems, appliances, VPN/IPsec gateways, and environments where untrusted users or workloads can access network namespace or XFRM-related functionality. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, kernel memory-corruption vulnerabilities can become high-priority quickly once reliable exploit techniques are published.

How an attack unfolds

An attacker first obtains local code execution with low privileges on a vulnerable Linux system. They then repeatedly exercise XFRM/IPsec state creation, lookup, SPI allocation, deletion, namespace cleanup, or flush paths to create timing and lifecycle conditions where an xfrm_state object is deleted or unhashed inconsistently. On vulnerable kernels, the delete path may attempt to remove list entries that are no longer valid or were never on the expected list, resulting in writes through stale hlist pointers. A simple attack may use this to trigger a kernel crash and deny service. A more advanced attack would groom kernel heap allocations around the freed xfrm_state object, reclaim the memory with attacker-influenced objects, and use the stale write primitive to corrupt kernel data structures, potentially leading to privilege escalation. Exploitation is local and generally depends on the attacker's ability to reach XFRM-related kernel paths, often through CAP_NET_ADMIN in a network namespace or equivalent local capability exposure.

How to fix it

Upgrade to a Linux kernel release that includes the XFRM fix changing the affected hash-list deletion logic to use hlist_del_init_rcu() and hlist_unhashed() checks for XFRM state list handling. No exact fixed package versions were provided in the input, so use the corrected kernel packages from the operating system vendor or upstream stable kernel trees once available for the deployed distribution and kernel branch. Prioritize kernels in the 6.12.y stable line and any other branches carrying the vulnerable XFRM code path. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling unprivileged user namespaces where operationally feasible, preventing untrusted containers from obtaining CAP_NET_ADMIN or host networking, and limiting access to IPsec/XFRM administration interfaces. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel version and vendor advisory status after remediation using commands such as uname -a and the distribution package manager's kernel changelog or security advisory metadata. Verify the active, booted kernel is the patched version, not only that a patched package is installed. Where source or vendor patch metadata is available, confirm the XFRM fix is present in net/xfrm/xfrm_state.c and that vulnerable hlist_del_rcu() usage in __xfrm_state_delete() has been replaced with defensive hlist_del_init_rcu() behavior and hlist_unhashed() checks for byseq/byspi. For exposure validation, identify systems with IPsec/XFRM usage, container runtimes, unprivileged user namespaces, or workloads granted CAP_NET_ADMIN. In non-production test environments, kernel fuzzing or regression tests that exercise XFRM state allocation, SPI allocation, flush, and network namespace teardown should no longer produce KASAN reports or kernel oopses in the xfrm_state lifecycle.

Typical attack path

1. Gain local execution on a vulnerable Linux host as a low-privileged user or within a workload/container that can exercise network namespace or XFRM/IPsec functionality.
2. Create or manipulate network namespaces and XFRM/IPsec state entries, including security associations, SPI allocation, state lookup, flush, and teardown operations.
3. Trigger repeated or racing XFRM state deletion and namespace cleanup paths so that the same xfrm_state list nodes are deleted inconsistently.
4. Cause kernel slab use-after-free or out-of-bounds writes in XFRM state hash-list handling.
5. Use the memory corruption to crash the kernel, or attempt heap grooming and kernel object corruption to escalate privileges.

How to detect it

Look for evidence in kernel logs, crash dumps, audit logs, and endpoint telemetry. Primary sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, systemd-journald, kdump/vmcore artifacts, kernel oops reports, and KASAN reports if debug kernels are deployed. Search for crashes or warnings involving XFRM state handling, IPsec state operations, network namespace cleanup, and functions such as __xfrm_state_delete, xfrm_state_delete, xfrm_state_flush, xfrm_state_fini, __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert, cleanup_net, and hlist_del_rcu. Also review audit logs or EDR telemetry for unusual local use of XFRM/IPsec tooling such as ip xfrm state/policy commands, frequent network namespace creation/deletion, privileged container launches, or workloads granted CAP_NET_ADMIN shortly before a crash. Because reliable exploitation may leave only a kernel crash or corrupted-memory artifact, absence of these indicators does not prove the vulnerability was not exercised. There are no known named threat actors or KEV exploitation reports in the provided data.

• BUG: KASAN: slab-use-after-free in __hlist_del
• BUG: KASAN: slab-use-after-free in hlist_del_rcu
• BUG: KASAN: slab-use-after-free in __xfrm_state_delete
• BUG: KASAN: slab-use-after-free in xfrm_alloc_spi
• BUG: KASAN: slab-use-after-free in __xfrm_state_lookup
• BUG: KASAN: slab-use-after-free in __xfrm_state_insert
• BUG: KASAN: slab-out-of-bounds in __xfrm_state_delete
• net/xfrm/xfrm_state.c
• __xfrm_state_delete
• xfrm_state_delete
• xfrm_state_flush
• xfrm_state_fini
• __xfrm_state_lookup
• xfrm_alloc_spi
• __xfrm_state_insert
• Workqueue: netns cleanup_net
• cleanup_net
• hlist_del_rcu
• LIST_POISON
• xfrm_state

What your security team should do

• Inventory Linux systems running affected kernel branches, especially 6.12.y kernels, container hosts, VPN/IPsec systems, shared servers, and systems allowing untrusted local workloads.
• Prioritize kernel updates on systems where local users, containers, CI jobs, or sandboxed workloads may obtain network namespace capabilities or CAP_NET_ADMIN.
• Track distribution-specific advisories for the exact fixed kernel package versions and ensure systems reboot into the patched kernel.
• Until patched, remove CAP_NET_ADMIN from untrusted containers and workloads, avoid privileged containers, restrict host networking, and disable unprivileged user namespaces where feasible.
• Monitor kernel logs for XFRM-related use-after-free, out-of-bounds write, KASAN, BUG, general protection fault, or panic messages that may indicate attempted triggering.
• Treat unexplained kernel crashes involving net/xfrm/xfrm_state.c, __xfrm_state_delete(), xfrm_alloc_spi(), or cleanup_net as potentially security-relevant and preserve logs, crash dumps, and workload context.
• Harden local privilege boundaries with SELinux/AppArmor/seccomp profiles and container runtime restrictions to reduce reachable kernel attack surface.