CVE-2026-64436

What it actually does

This is a Linux kernel memory-safety flaw in the AF_KEY/PF_KEY IPsec key-management path for IPComp security associations. When an IPComp state is created through PF_KEY, the kernel allocates an XFRM compression algorithm structure but fails to initialize alg_key_len. During a later XFRM migration operation, that uninitialized value is treated as a length, causing kmemdup() to read beyond the end of the allocated object or attempt an oversized allocation. The result can be a kernel slab out-of-bounds read, kernel fault/panic, failed migration, and potential exposure of adjacent kernel memory contents depending on allocator state and system hardening. The XFRM netlink SA creation path is described as not affected because it validates the compression algorithm attribute length.

Why it matters to the business

An attacker with local privileges sufficient to manipulate IPsec/XFRM state may be able to crash affected Linux systems or potentially read sensitive kernel memory. For servers, appliances, VPN gateways, container hosts, and network devices that expose IPsec/XFRM functionality to privileged local users or delegated containers, the main operational risk is service disruption and possible confidentiality loss. The vulnerability is not currently listed in CISA KEV, has no reported ransomware association, and has a very low EPSS score, so internet-scale exploitation is not indicated; however, local kernel bugs should still be prioritized on multi-user systems, shared hosting, and systems where containers or service accounts may hold network administration capabilities.

How an attack unfolds

An attacker first needs local code execution with enough privilege to create or manipulate IPsec security associations through the PF_KEY interface and trigger XFRM migration. They create an IPComp security association using PF_KEY, causing the kernel to allocate the compression algorithm structure without clearing alg_key_len. They then trigger an XFRM migration operation for that state. During migration, the kernel clones the algorithm structure and computes the copy size from the uninitialized alg_key_len value. If the stale slab value is non-zero, the clone operation may read past the end of the object or request an unexpectedly large allocation. In practice this can produce a kernel warning, KASAN report, oops, panic, or failed migration; under favorable conditions, the out-of-bounds read may expose adjacent kernel memory to kernel paths that copy or log the cloned state.

How to fix it

Apply the vendor kernel update that initializes the IPComp compression algorithm key length to zero in the AF_KEY/PF_KEY path. If fixed package versions are not yet published for a distribution, track the relevant Linux kernel and distribution advisories and upgrade as soon as patched kernels are available. As temporary risk reduction, restrict local users and containers from obtaining CAP_NET_ADMIN or equivalent privileges, avoid delegating IPsec/XFRM management to untrusted workloads, disable or avoid PF_KEY/IPComp functionality where not required, and consider kernel hardening options that reduce information disclosure impact. On systems where IPsec/IPComp is not used, remove unnecessary tooling and limit access to interfaces used to manage XFRM state, but do not rely on this as a substitute for patching.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor fix for the AF_KEY IPComp alg_key_len initialization issue. Use the distribution package manager and security advisories to verify the installed kernel build is at or above the fixed release once available, and reboot into the fixed kernel. For source-based or custom kernels, inspect the PF_KEY IPComp handling in pfkey_msg2xfrm_state() and verify the compression algorithm structure explicitly sets alg_key_len to 0 before the state can be migrated. Validate that no outdated kernels remain bootable or running by comparing package inventory with `uname -r`. In controlled non-production testing only, a regression test that creates an IPComp SA through PF_KEY and triggers XFRM migration should no longer produce KASAN, slab out-of-bounds, kernel oops, or migration clone failures related to xfrm_algo_clone().

Typical attack path

1. Obtain local execution on an affected Linux system.
2. Gain or abuse privileges that allow PF_KEY/IPsec/XFRM state manipulation, such as network-administration capability in the relevant namespace.
3. Open/use the PF_KEY interface to add an IPComp security association.
4. Ensure the IPComp state is created through the PF_KEY path where the compression algorithm key length is not initialized.
5. Trigger XFRM migration for the affected state.
6. Cause the kernel to clone the malformed compression algorithm structure, resulting in an out-of-bounds read or oversized allocation attempt.
7. Leverage the outcome for denial of service, crash evidence removal attempts, or possible kernel memory disclosure depending on system behavior.

How to detect it

Detection is primarily forensic because this flaw does not create a distinctive file, process, or network beacon. Review kernel logs, journal logs, crash dumps, audit records, and process accounting for sequences involving PF_KEY IPComp security-association creation followed by XFRM migration and kernel memory errors. Relevant log sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, auditd syscall logs, eBPF/EDR telemetry for socket and netlink activity, kdump/vmcore artifacts, and container runtime logs showing workloads granted CAP_NET_ADMIN. Look for KASAN or slab out-of-bounds reports in kmemdup/kmemdup_noprof with stack frames containing xfrm_state_migrate, xfrm_migrate, xfrm_do_migrate, pfkey_add, pfkey_process, or pfkey_sendmsg. Also investigate unexpected reboots, kernel panics, XFRM migration failures, and oversized allocation failures occurring near local processes that manage IPsec, PF_KEY, or XFRM state. Because legitimate VPN/IPsec software may use related interfaces, correlate events with change windows and known administrative activity before declaring malicious use.

• BUG: KASAN: slab-out-of-bounds in kmemdup
• BUG: KASAN: slab-out-of-bounds in kmemdup_noprof
• slab-out-of-bounds in kmemdup_noprof
• xfrm_state_migrate
• xfrm_state_clone_and_setup
• xfrm_algo_clone
• xfrm_alg_len
• xfrm_migrate
• xfrm_do_migrate
• xfrm_user_rcv_msg
• xfrm_netlink_rcv
• pfkey_add
• pfkey_process
• pfkey_sendmsg
• SADB_X_SATYPE_IPCOMP
• XFRM_MSG_MIGRATE
• IPComp
• calg->alg_key_len
• Read of size 4164
• kmalloc-96
• allocated 68-byte region

What your security team should do

• Inventory Linux systems that run IPsec, XFRM, VPN, container networking, network appliances, or workloads with CAP_NET_ADMIN.
• Prioritize patching multi-user systems, shared compute, container hosts, VPN gateways, and systems where non-root service accounts or containers can administer networking.
• Remove CAP_NET_ADMIN and similar network-management privileges from containers and service accounts unless strictly required.
• Monitor kernel, audit, and system logs for PF_KEY/IPComp activity followed by XFRM migration errors, KASAN reports, kernel oopses, or unexplained reboots.
• If exploitation is suspected, preserve kernel logs, crash dumps, audit logs, process accounting, and container/runtime metadata before rebooting or rotating logs.
• Disable or avoid IPComp/PF_KEY workflows where operationally unnecessary until patched.
• Track vendor advisories for the exact fixed kernel package and ensure systems are rebooted into the patched kernel, not merely updated on disk.