CVE-2026-31663

What it actually does

This is a race condition in the Linux kernel XFRM/IPsec receive path. During asynchronous crypto processing, the kernel can release a network device reference too early, while the packet buffer still contains a pointer to that device. The packet later reaches Netfilter transport handling, where that stale device pointer may be used after the underlying network device has been torn down. Technically, this can create a use-after-free condition in kernel memory. A local attacker with sufficient ability to exercise XFRM/IPsec and network-device lifecycle paths may be able to trigger kernel memory corruption, potentially causing denial of service or, in a successful exploit, local privilege escalation with kernel-level impact to confidentiality, integrity, and availability.

Why it matters to the business

Successful exploitation could allow a local attacker to crash affected Linux systems or potentially gain elevated privileges, which may lead to service outages, host compromise, tampering with workloads, or access to sensitive data on the same system. The vulnerability is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score with a flat 30-day trend, so broad internet-scale exploitation is not currently indicated. However, because this is a kernel flaw with high-impact outcomes, organizations running Linux systems that use IPsec/XFRM, container networking, network namespaces, virtual interfaces, or dynamic network-device creation and teardown should treat remediation as important.

How an attack unfolds

An attacker first needs local access to an affected Linux host and enough privileges or namespace capabilities to influence relevant networking behavior. They then attempt to drive traffic through the XFRM/IPsec receive path where asynchronous crypto processing is used. While packets are being resumed after crypto completion, the attacker concurrently causes network-device teardown or lifecycle changes, such as removing virtual interfaces or network namespaces. In the vulnerable path, the kernel may drop the device reference before Netfilter transport handling has finished. If timing is favorable, later Netfilter processing dereferences the stale skb->dev pointer after the device memory has been released. The most likely observable result is a kernel crash or panic; with reliable heap shaping and precise timing, the memory corruption condition could potentially be turned into local privilege escalation.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the XFRM fix which holds the network-device reference until after transport_finish Netfilter processing and releases it correctly on non-transport and async exit paths. Because no fixed versions were provided in the input, use your Linux distribution or kernel vendor advisory to identify the exact patched kernel package for this CVE. Prioritize systems that use IPsec, XFRM policies, strongSwan/libreswan, VPN gateways, container hosts, Kubernetes nodes, network namespaces, virtual interfaces, or high churn in network-device lifecycle. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting CAP_NET_ADMIN and privileged containers, disabling unneeded IPsec/XFRM functionality, limiting creation of network namespaces or virtual interfaces by untrusted users, and applying standard kernel hardening controls such as module restrictions, unprivileged user namespace restrictions where operationally feasible, and rapid reboot into patched kernels after updates.

How to confirm the fix worked

Confirm that each Linux host is running a kernel build from the relevant distribution or vendor that contains the upstream XFRM reference-lifetime fix. Validate by checking the installed and running kernel versions, not only the package inventory, because kernel updates usually require rebooting. Use vendor changelogs, security advisories, or package metadata to confirm the fix for CVE-2026-31663 is included. For exposure validation, identify hosts with active XFRM/IPsec use by checking for configured XFRM states or policies and IPsec services. Confirm whether untrusted users, containers, or workloads can create network namespaces, virtual interfaces, or hold CAP_NET_ADMIN. After remediation, reboot into the patched kernel and verify that the running kernel matches the patched package version. In test environments, regression-test IPsec/VPN traffic, Netfilter rules, and container networking after the kernel update.

Typical attack path

1. Obtain local execution on a vulnerable Linux system.
2. Gain or use networking-related privileges, namespace capabilities, or access to a context that can exercise XFRM/IPsec and device teardown paths.
3. Configure or trigger XFRM/IPsec traffic that uses asynchronous crypto handling.
4. Race packet processing completion against network-device teardown, such as virtual interface or namespace destruction.
5. Cause Netfilter transport handling to use a stale skb->dev pointer after the device reference has been released.
6. Trigger kernel memory corruption, usually resulting in a crash and potentially enabling privilege escalation if exploitation is reliable.

How to detect it

Detection should focus on evidence of attempted triggering, kernel instability, and suspicious local activity around XFRM/IPsec and network-device lifecycle changes. Review kernel logs from journald, syslog, dmesg, crash dumps, kdump/vmcore, auditd, EDR telemetry, and container runtime logs. Look for kernel warnings, panics, KASAN/KFENCE use-after-free reports, general protection faults, NULL or invalid pointer dereferences, and call traces involving XFRM receive/resume handling, Netfilter hooks, transport_finish, or network-device cleanup. Correlate crashes with bursts of IPsec/XFRM traffic, creation and deletion of network namespaces, virtual Ethernet pairs, tunnel interfaces, or teardown of container networking. Audit for unexpected use of CAP_NET_ADMIN, privileged containers, ip xfrm commands, ip link deletion, namespace manipulation, or IPsec configuration changes by non-administrative users. There are no known public threat actors or ransomware campaigns tied to this CVE from the provided data, and no reliable network-only signature is derivable because exploitation is local and timing-dependent.

• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• general protection fault
• kernel panic
• Oops:
• Call Trace:
• xfrm_input_resume
• transport_finish
• NF_HOOK
• nf_hook_slow
• dev_put
• skb->dev
• xfrm_input
• xfrm4_transport_finish
• xfrm6_transport_finish
• unregister_netdevice
• ip xfrm state
• ip xfrm policy
• CAP_NET_ADMIN
• RTM_DELLINK
• veth
• ip link delete
• ip netns delete

What your security team should do

• Identify affected Linux assets and prioritize kernel updates on systems using IPsec/XFRM, VPN services, container networking, or dynamic virtual network interfaces.
• Patch through the operating system vendor’s kernel update channel and ensure hosts are rebooted into the fixed kernel.
• Restrict CAP_NET_ADMIN, privileged containers, and untrusted access to network namespaces or virtual interface creation until remediation is complete.
• Review VPN gateways, Kubernetes/container hosts, and multi-user Linux servers first because they are more likely to expose the vulnerable code path to less-trusted actors.
• Monitor kernel logs for crashes, use-after-free reports, XFRM stack traces, and suspicious correlation between IPsec traffic and interface or namespace teardown.
• Because this is not currently KEV-listed, has no known mature exploit, and has low EPSS, prioritize based on exposure and kernel criticality rather than emergency internet-wide exploitation assumptions.
• Maintain an inventory process that distinguishes installed kernel packages from the currently running kernel so incomplete remediation after patching is detected.