CVE-2026-64009

What it actually does

This is a local Linux kernel memory-corruption flaw in the XFRM/IPsec ESP output path. The vulnerable code calculates an ESP tunnel MTU using unsigned arithmetic and can underflow when attacker-controlled ESP parameters, authentication truncation size, traffic-flow-confidentiality padding, and a very small interface MTU are combined. The underflowed value is later treated as a signed length, becomes negative, and is then sign-extended into a very large size_t passed to memset(), causing an out-of-bounds kernel memory write near the socket buffer tail. Practical impact can include kernel crash, denial of service, and potentially local privilege escalation or arbitrary kernel memory corruption, depending on exploit reliability and platform hardening.

Why it matters to the business

A user with low privileges on an affected Linux system may be able to crash the host or potentially gain elevated privileges by abusing the kernel IPsec networking stack. Systems that allow unprivileged user namespaces, containerized workloads, or delegated network administration capabilities are at higher risk because these configurations can make kernel networking attack surfaces reachable by less-trusted users. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, but it affects a high-impact kernel component where successful exploitation can compromise host availability and integrity.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user. If permitted by system policy, the attacker creates or uses a network namespace where they can configure XFRM/IPsec state. They install an IPv4 ESP tunnel security association using a large authentication/truncation configuration, configure a very small interface MTU, and set a large XFRM traffic-flow-confidentiality padding value. The attacker then sends a UDP datagram through the ESP tunnel. During ESP output processing, the kernel computes an invalid near-maximum MTU due to unsigned underflow, derives a negative ESP padding length, and passes that value into a memory-setting operation as a huge unsigned length. This triggers an out-of-bounds write in kernel memory, commonly observable as a KASAN report or kernel oops; with further exploit development it may be usable for privilege escalation, while straightforward triggering may cause a denial of service.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the fix for the XFRM xfrm_state_mtu() underflow check. Because no exact affected products or fixed package versions were provided, use vendor advisories for the deployed distribution and confirm the patched kernel contains the change that detects underflow in xfrm_state_mtu() and returns a safe failure value. Reboot into the patched kernel after installation; merely installing the package is insufficient if the running kernel is unchanged. Where immediate patching is not possible, reduce exposure by disabling unprivileged user namespaces where operationally feasible, restricting CAP_NET_ADMIN and container network-administration capabilities, limiting use of XFRM/IPsec configuration to trusted administrators, and preventing untrusted workloads from creating network namespaces or configuring IPsec state. These mitigations reduce reachability but should not be treated as a permanent substitute for patching.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated to a vendor build containing the XFRM underflow fix. Validate with uname -a, distribution package tools, and the applicable vendor security advisory. On source-based or custom kernels, confirm the xfrm_state_mtu() implementation checks for underflow before subtracting ESP header, authentication, and padding adjustments. Review whether unprivileged user namespaces are enabled and whether untrusted users or containers can obtain CAP_NET_ADMIN. Functional validation can include verifying that attempts to send traffic through the previously vulnerable ESP configuration fail safely, such as with ENETUNREACH, rather than producing a kernel oops, KASAN report, or host crash. Do not run proof-of-concept triggers on production systems because the vulnerable behavior is kernel memory corruption.

Typical attack path

1. Gain local execution on an affected Linux system as an unprivileged or low-privileged user.
2. Obtain access to XFRM/IPsec configuration, commonly via CAP_NET_ADMIN in a network namespace if unprivileged user namespaces are enabled.
3. Create an IPv4 ESP tunnel security association with attacker-selected authentication truncation parameters, such as hmac(sha512) with a large truncation size.
4. Configure a small interface MTU, such as the IPv4 minimum MTU of 68 bytes.
5. Set a large XFRM traffic-flow-confidentiality padding value using XFRMA_TFCPAD.
6. Send a UDP packet through the ESP tunnel to reach the vulnerable esp_output() path.
7. Trigger unsigned underflow in xfrm_state_mtu(), causing a negative padding length to be converted to a very large memory write length.
8. Cause kernel memory corruption, typically resulting in a crash and potentially enabling local privilege escalation if weaponized.

How to detect it

Post-exploitation detection is difficult because successful exploitation occurs inside the kernel and may leave only crash, oops, audit, or command-history artifacts. Review kernel logs, system journal, crash dumps, KASAN reports, and panic records for out-of-bounds writes or call traces involving ESP/XFRM functions, especially xfrm_state_mtu(), esp_output(), and esp_output_fill_trailer(). Search for very large KASAN write sizes, negative ESP padding symptoms, or crashes shortly after IPsec/XFRM configuration changes. Review auditd, eBPF, shell history, EDR, and container runtime telemetry for low-privileged users creating network namespaces, acquiring CAP_NET_ADMIN, running ip xfrm commands, configuring IPv4 ESP tunnel security associations, setting very small MTUs such as 68 bytes, or using large XFRM traffic-flow-confidentiality padding. Also inspect /proc/net/xfrm_stat, ip xfrm state, and network namespace inventory for unexpected ESP tunnel state. Because no public exploit maturity or named threat actors were provided, prioritize anomaly-based detection around local privilege-boundary abuse and kernel crash correlation rather than relying solely on known malware indicators.

• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• Write of size 184467440737095515
• esp_output_fill_trailer
• xfrm_state_mtu
• esp_output
• xfrm_output_resume
• XFRMA_TFCPAD
• XFRMA_ALG_AUTH_TRUNC
• hmac(sha512)
• ip xfrm state add
• ip xfrm policy add
• mtu 68
• NETLINK_XFRM
• ENETUNREACH

What your security team should do

• Prioritize patching Linux hosts that allow local shell access, multi-tenant workloads, containers, unprivileged user namespaces, or delegated network administration capabilities.
• Inventory systems using XFRM/IPsec ESP and systems where users or containers can create network namespaces or hold CAP_NET_ADMIN.
• Apply vendor kernel updates and reboot into the fixed kernel; verify the running kernel version after reboot.
• Temporarily disable unprivileged user namespaces or restrict them to trusted workloads where feasible.
• Remove CAP_NET_ADMIN from containers and service accounts unless explicitly required.
• Monitor kernel logs and crash telemetry for KASAN, oops, panic, or call traces involving xfrm_state_mtu, esp_output, or esp_output_fill_trailer.
• Review audit and command telemetry for suspicious creation of XFRM ESP tunnel states, unusually small MTUs, and large XFRM traffic-flow-confidentiality padding values.
• Treat unexpected kernel crashes on systems with local untrusted users as potential security events and preserve logs, crash dumps, and recent process/audit history.