CVE-2026-53239

What it actually does

This is a Linux kernel use-after-free in the XFRM/IPsec policy subsystem. A race exists between deleting an XFRM policy and rebuilding or flushing inexact policy bins: one CPU can retain a pointer to an inexact policy bin after dropping xfrm_policy_lock, while another CPU frees that bin via RCU during XFRM policy hash rebuild. Subsequent use of the stale bin pointer can trigger kernel memory corruption, a kernel crash, or potentially privilege escalation depending on allocator state, kernel hardening, and attacker control over heap reuse. Exploitation requires the ability to exercise XFRM policy management paths, typically through Netlink XFRM operations such as policy deletion and SPD information updates.

Why it matters to the business

Successful exploitation can destabilize Linux systems by causing kernel panics or networking/IPsec subsystem failures, resulting in service outages for workloads that rely on affected kernels. If weaponized beyond denial of service, the flaw could potentially allow local privilege escalation to kernel-level control. The current EPSS score is low, the vulnerability is not listed in CISA KEV, and no public exploit maturity is reported, so broad active exploitation is not currently indicated; however, kernel race conditions can become more serious once reliable exploit techniques emerge.

How an attack unfolds

An attacker first needs a way to issue XFRM policy-management requests to the kernel, most plausibly from a local context with sufficient privileges or capabilities to manipulate XFRM/IPsec state. The attacker then creates conditions where one execution path deletes an XFRM policy using the policy selector/context lookup flow while another execution path triggers a Security Policy Database information update that rebuilds or flushes XFRM policy hash structures. By carefully timing XFRM_MSG_DELPOLICY and XFRM_MSG_NEWSPDINFO activity, the attacker attempts to make the delete path keep a pointer to an inexact policy bin after the lock is released, while the rebuild path frees that same bin. When the delete path later prunes the previously freed bin, the kernel dereferences freed memory. In many cases this will manifest as a kernel oops, panic, or KASAN use-after-free report; in a more advanced scenario, an attacker may try to groom kernel heap memory so the stale pointer references attacker-influenced data, potentially turning the memory safety bug into privilege escalation.

How to fix it

Upgrade to a kernel version that includes the upstream XFRM policy locking fix for this issue. Because no product-specific affected or fixed versions were provided, remediation should be driven by the Linux distribution or appliance vendor advisory for the running kernel branch. Prioritize systems that expose local user access, run containers with elevated network capabilities, use IPsec/XFRM heavily, or allow administrative automation to manipulate IPsec policy state. If immediate patching is not possible, reduce exposure by limiting untrusted local shell/container access, removing unnecessary CAP_NET_ADMIN privileges, restricting access to Netlink XFRM policy management, disabling unused IPsec/XFRM functionality where operationally feasible, and enforcing kernel hardening features such as lockdown, module restrictions, KASLR, slab freelist hardening, and panic handling appropriate for the environment.

How to confirm the fix worked

Confirm the running kernel package includes the vendor backport or upstream commit that moves pruning of the inexact bin under xfrm_policy_lock in xfrm_policy_bysel_ctx(). Validate by checking distribution security advisories, kernel changelogs, and package versions rather than relying only on the upstream version number, because enterprise distributions commonly backport fixes. On systems with kernel debug facilities, absence of KASAN or kernel oops reports involving xfrm_policy_bysel_ctx(), xfrm_policy_inexact_prune_bin(), xfrm_hash_rebuild(), or __xfrm_policy_inexact_flush() after stress testing XFRM policy create/delete/rebuild operations can provide additional assurance. Also verify that untrusted users and containers do not have CAP_NET_ADMIN or equivalent access that would allow XFRM policy manipulation.

Typical attack path

1. Obtain local execution on a Linux system with access to XFRM/IPsec policy management interfaces and the required privileges or capabilities.
2. Create or manipulate XFRM policies so that inexact policy bins are present in the kernel policy table.
3. Concurrently issue XFRM policy deletion operations and SPD information update or hash rebuild operations.
4. Win the race where one thread retains a pointer to an inexact bin while another thread frees it under the XFRM policy lock.
5. Trigger pruning or further processing of the stale bin pointer, causing a kernel use-after-free.
6. Cause a denial of service through kernel crash, or attempt heap grooming to pursue kernel-level code execution or privilege escalation.

How to detect it

Review kernel logs, crash dumps, audit logs, and Netlink activity for evidence of attempted race triggering or resulting kernel instability. Useful sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, kdump/vmcore analysis, auditd records for CAP_NET_ADMIN activity, container runtime logs showing privileged or CAP_NET_ADMIN containers, and IPsec/XFRM management logs from tools or daemons that modify Security Policy Database state. Look for kernel oops, panic, KASAN, KFENCE, UBSAN, or general protection fault reports with stack traces containing xfrm_policy_bysel_ctx(), xfrm_policy_inexact_prune_bin(), xfrm_hash_rebuild(), __xfrm_policy_inexact_flush(), or XFRM policy deletion/rebuild code. Also investigate bursts of XFRM Netlink operations, especially repeated policy deletes combined with SPD information updates, from unexpected local users, containers, automation accounts, or processes. There are no known network-level indicators specific to exploitation because the vulnerable operation is inside local kernel XFRM policy management rather than a remote packet parser.

• BUG: KASAN: use-after-free in xfrm_policy_inexact_prune_bin
• BUG: KASAN: use-after-free in xfrm_policy_bysel_ctx
• xfrm_policy_bysel_ctx
• xfrm_policy_inexact_prune_bin
• xfrm_hash_rebuild
• __xfrm_policy_inexact_flush
• XFRM_MSG_DELPOLICY
• XFRM_MSG_NEWSPDINFO
• general protection fault: xfrm_policy
• kernel BUG at net/xfrm/xfrm_policy.c
• Oops: 0000 [#1]
• Call Trace: xfrm_policy_bysel_ctx
• Call Trace: xfrm_hash_rebuild
• NETLINK_XFRM
• CAP_NET_ADMIN

What your security team should do

• Inventory Linux systems and appliances using kernels that include the XFRM/IPsec subsystem, especially systems using IPsec, VPN, container networking, or network security functions.
• Check vendor advisories for the exact fixed kernel packages for each distribution and schedule kernel updates with reboot coordination.
• Prioritize patching multi-user systems, container hosts, VPN/IPsec gateways, and any host where untrusted users or workloads may have CAP_NET_ADMIN or access to network namespace administration.
• Until patched, restrict CAP_NET_ADMIN, privileged containers, user namespaces where applicable, and administrative paths that can issue XFRM Netlink operations.
• Monitor kernel logs for crashes, KASAN reports, call traces, or warnings referencing XFRM policy functions.
• Treat unexplained kernel panics involving XFRM policy paths as potentially security relevant and preserve logs, vmcores, and audit records for investigation.
• Because the vulnerability is not currently KEV-listed and EPSS is low, align urgency with exposure: high priority for exposed multi-tenant or containerized systems; normal kernel patch cadence may be acceptable for tightly controlled single-purpose systems.