CVE-2026-63919

What it actually does

This is a Linux kernel use-after-free in the XFRM/IPsec transport-mode packet reinjection path. Deferred reinjection stores a network namespace pointer in packet control metadata and later uses it from a workqueue callback; without holding a reference to that namespace, the namespace can be freed during teardown before the callback runs. If triggered, the kernel may dereference freed memory, causing a crash, memory corruption, or potentially kernel-mode code execution. Because exploitation occurs in kernel networking code, successful exploitation can compromise confidentiality, integrity, and availability of the host.

Why it matters to the business

Systems running affected Linux kernels may be exposed to host crashes or full kernel compromise by an attacker who has the privileges needed to manipulate networking namespaces and XFRM/IPsec state or traffic. The CVSS score is high, but the currently reported EPSS is low, it is not listed in CISA KEV, and no public exploit maturity is reported, so immediate emergency response is less indicated than for actively exploited issues; however, kernel flaws with privilege-escalation or crash potential should still be patched on a prioritized maintenance timeline, especially on multi-tenant, container, VPN, IPsec, or namespace-heavy workloads.

How an attack unfolds

An attacker first gains the ability to run code or otherwise perform privileged network operations sufficient to create or tear down network namespaces and exercise XFRM/IPsec transport-mode processing. They then arrange for traffic to enter the XFRM transport reinjection path, causing deferred work to be queued with a reference to a network namespace. By racing namespace teardown against the deferred reinjection callback, the attacker attempts to make the callback use a namespace object after it has been freed. The most likely visible outcome is a kernel oops, panic, or denial of service; with reliable heap shaping and kernel exploitation capability, the same memory corruption primitive may be developed into privilege escalation or kernel code execution.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for XFRM deferred transport reinjection namespace lifetime handling, specifically the change that takes a net namespace reference when queuing deferred reinjection work and releases it after the callback completes. Because no fixed package versions were provided, use the fixed kernel versions published by the operating system, appliance, container-host, or distribution vendor. Where immediate patching is not possible, reduce exposure by limiting who can create network namespaces, containers, and XFRM/IPsec state; disabling unneeded IPsec/XFRM functionality where operationally feasible; restricting unprivileged user namespaces if enabled; and isolating workloads that require advanced network namespace capabilities.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or source tree contains the fix titled similar to "xfrm: input: hold netns during deferred transport reinjection" and that the system has rebooted into the patched kernel. Validate with vendor package metadata, kernel changelogs, or source inspection for net namespace reference handling around xfrm_trans_queue_net() and xfrm_trans_reinject(). On test systems, run XFRM/IPsec transport-mode and network namespace lifecycle regression tests while monitoring dmesg for KASAN, use-after-free, workqueue, XFRM, or kernel oops messages. Exposure can be assessed by checking whether systems use IPsec/XFRM transport mode, run containers or network namespaces, or grant users/container runtimes permissions that can manipulate network namespaces and XFRM state.

Typical attack path

1. Obtain local code execution or equivalent privileges that allow manipulation of Linux network namespaces and XFRM/IPsec configuration.
2. Create or use a network namespace with XFRM/IPsec transport-mode state and traffic that triggers deferred transport reinjection.
3. Cause packets to be queued for deferred reinjection via the XFRM input path.
4. Race network namespace teardown or cleanup against the deferred workqueue callback.
5. Trigger use of the stale net namespace pointer in the reinjection callback.
6. Cause a kernel crash, or attempt to convert the use-after-free into kernel memory corruption for privilege escalation.

How to detect it

Look for evidence of attempted triggering or successful exploitation in kernel logs, persistent journal logs, crash dumps, and EDR telemetry. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k output, kdump/vmcore artifacts, hypervisor reset records, and container-runtime audit logs showing unusual network namespace creation or teardown. Search for kernel oops, panic, KASAN, KFENCE, general protection fault, slab use-after-free, or workqueue crashes that include XFRM functions such as xfrm_trans_reinject(), xfrm_trans_queue_net(), or XFRM input processing. Also review audit logs for suspicious or repeated use of ip xfrm commands, network namespace lifecycle activity, CAP_NET_ADMIN-enabled containers, and rapid namespace teardown around the time of kernel crashes. There are no known public attacker IPs, malware filenames, or network payload signatures specific to this vulnerability from the provided information.

• xfrm_trans_reinject
• xfrm_trans_queue_net
• xfrm_input
• xfrm: input
• BUG: KASAN: use-after-free
• BUG: KFENCE: use-after-free
• use-after-free in xfrm_trans_reinject
• general protection fault
• kernel NULL pointer dereference
• kernel panic
• Oops:
• Workqueue:
• netns
• ip xfrm
• /var/crash/vmcore
• /proc/vmcore
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching Linux kernels on container hosts, VPN/IPsec gateways, systems using XFRM transport mode, and multi-user or multi-tenant Linux systems.
• Track vendor advisories for the exact fixed kernel package and schedule a reboot into the patched kernel; kernel package installation alone is not sufficient if the old kernel remains running.
• Restrict creation of network namespaces and unprivileged user namespaces where business requirements allow.
• Limit CAP_NET_ADMIN and other networking capabilities in containers and service units to only workloads that require them.
• Review dmesg, kernel logs, crash dumps, and EDR telemetry for kernel oops or KASAN use-after-free events involving XFRM reinjection functions.
• If suspicious crashes are observed, preserve vmcore/crash dumps before reboot cycles overwrite evidence.
• Because this is not currently KEV-listed and EPSS is low, handle as high-severity preventive hardening unless local indicators show active exploitation.