CVE-2026-64114

What it actually does

This flaw is an input-validation bug in the Linux kernel IPv4 raw-socket transmit path. A local process with CAP_NET_RAW can supply its own IPv4 header using IP_HDRINCL and set the IPv4 Internet Header Length field to an invalid value below the RFC minimum of 5. The kernel validates that the computed header length is not larger than the message but fails to reject values smaller than a normal IPv4 header. The malformed packet can then enter the local output path unchanged. In the AH/IPsec output path, downstream code assumes a valid header length, subtracts the base IPv4 header size, and can convert a negative length into a very large size_t used by memcpy(), causing an out-of-bounds kernel memory access and kernel panic. Exploitability is local and requires raw-packet capability; in some configurations this can be reachable from containers or user/network namespaces, especially where unprivileged user namespaces are enabled and containers are granted NET_RAW and NET_ADMIN capabilities.

Why it matters to the business

Successful exploitation can crash the affected Linux host, interrupting workloads, containers, network services, and dependent applications. In containerized environments, a tenant or compromised container with the required Linux capabilities may be able to impact the underlying host or shared infrastructure, turning a limited local foothold into an operational outage. The vulnerability is not currently listed in CISA KEV and has low EPSS at the time of assessment, but kernel-level denial-of-service issues should still be prioritized on multi-tenant systems, container hosts, VPN/IPsec gateways, and systems that allow user namespaces or grant raw networking capabilities.

How an attack unfolds

An attacker first obtains local code execution on a Linux system or inside a container with access to CAP_NET_RAW. To reach the demonstrated crash path, the attacker also needs conditions that route the crafted packet through IPv4 AH/IPsec output handling, such as an applicable xfrm AH policy and state on a non-loopback interface; a container with CAP_NET_ADMIN may be able to create this within its network namespace. The attacker opens a raw IPv4 socket, enables IP_HDRINCL, and sends a packet whose caller-supplied IPv4 header reports an invalid IHL value below 5. The raw socket code accepts the malformed header because it checks only whether the computed header length exceeds the message length, not whether it is too small. The packet then enters the kernel output path. When AH processing evaluates the invalid IHL, it calculates a negative options length, casts it to an unsigned size, and passes an extremely large length to memcpy(), causing an out-of-bounds access and kernel panic.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the fix for rejecting IPv4 raw IP_HDRINCL packets when the computed header length is smaller than sizeof(struct iphdr). No exact fixed package versions were provided in the input, so use vendor advisories, kernel changelogs, and package metadata to identify the corrected build for each distribution and kernel stream. Where immediate patching is not possible, reduce exposure by removing CAP_NET_RAW and CAP_NET_ADMIN from containers and services that do not require them, disabling or restricting unprivileged user namespaces where operationally feasible, applying seccomp or container runtime policies that block raw socket creation, and limiting the ability of untrusted workloads to configure xfrm/IPsec state. Avoid granting NET_ADMIN to rootless or multi-tenant containers unless strictly required.

How to confirm the fix worked

Confirm that running kernels have been updated to a vendor build containing the raw IPv4 IP_HDRINCL IHL validation fix. Review kernel source or vendor patches for a check equivalent to rejecting iphlen < sizeof(*iph) in the IPv4 raw send path. Validate package status using distribution tooling and verify the active booted kernel, not only the installed package. On non-production test systems, a controlled regression test can attempt to send a malformed IP_HDRINCL packet with IHL below 5 and should receive an error such as EINVAL rather than causing a kernel crash. Also review host and container configurations to confirm untrusted workloads do not retain CAP_NET_RAW or CAP_NET_ADMIN, and verify whether CONFIG_USER_NS is enabled and whether unprivileged user namespace creation is allowed.

Typical attack path

1. Gain local code execution on an affected Linux system, container, or namespace.
2. Obtain or abuse CAP_NET_RAW to create raw IPv4 sockets; in some deployments this may be available inside user and network namespaces.
3. If targeting the AH crash path, obtain CAP_NET_ADMIN or equivalent control to configure matching xfrm AH policy and state on an outgoing non-loopback route.
4. Open an IPv4 raw socket and enable IP_HDRINCL so the process supplies its own IP header.
5. Craft an IPv4 packet with an invalid IHL value less than 5 while keeping the message length large enough to pass the existing size check.
6. Send the packet through a route that invokes IPv4 AH/IPsec output processing.
7. Trigger an out-of-bounds kernel memory access in AH output handling, typically resulting in a kernel oops or panic and service disruption.

How to detect it

Look for evidence of attempted or successful local exploitation in kernel logs, crash dumps, audit logs, and container runtime telemetry. Successful exploitation is likely to appear as a kernel oops, panic, KASAN report, or crash dump with stack frames involving IPv4 AH/IPsec output handling, memcpy, xfrm output, and raw IPv4 send paths. Review /var/log/kern.log, /var/log/messages, journalctl -k, pstore, kdump/vmcore analysis, and centralized Linux telemetry for crashes referencing ah_output, ah4.c, memcpy_orig, xfrm_output, __ip_local_out, or raw_send_hdrinc. To identify precursor behavior, review auditd/eBPF/EDR telemetry for untrusted processes creating AF_INET SOCK_RAW sockets, setting IP_HDRINCL, adding xfrm AH policy or state, or containers started with NET_RAW/NET_ADMIN capabilities. Container platform logs should be checked for workloads launched with elevated networking capabilities shortly before a host panic. Because malformed packet contents are generated locally and may not traverse external network sensors, host-based logs and kernel crash artifacts are the most reliable evidence sources.

• BUG: kernel NULL pointer dereference
• kernel-mode fault at addr 0x0
• KASAN: null-ptr-deref
• KASAN: wild-memory-access
• memcpy_orig
• ah_output
• net/ipv4/ah4.c
• xfrm_output
• __ip_local_out
• raw_send_hdrinc
• IP_HDRINCL
• SOCK_RAW
• AF_INET, SOCK_RAW
• CAP_NET_RAW
• CAP_NET_ADMIN
• RTM_NEWPOLICY
• RTM_NEWSA
• xfrm_user
• ip xfrm state add
• ip xfrm policy add
• --cap-add NET_ADMIN
• --cap-add NET_RAW

What your security team should do

• Prioritize patching Linux kernel packages on container hosts, multi-tenant systems, IPsec/VPN infrastructure, CI runners, and systems that allow untrusted local code execution.
• Inventory workloads and containers granted NET_RAW or NET_ADMIN and remove those capabilities wherever they are not strictly required.
• Restrict unprivileged user namespaces on systems where they are not needed, especially shared or internet-facing workload platforms.
• Add runtime policy controls, such as seccomp, AppArmor, SELinux, or container runtime defaults, to prevent untrusted processes from creating raw sockets or configuring xfrm state.
• Review kernel crash telemetry, system logs, and audit logs for signs of recent panics involving IPv4 AH output, xfrm output, raw sockets, or suspicious namespace/container capability use.
• Ensure crash dumping, kdump, and centralized log forwarding are enabled on high-value Linux systems so future kernel panics can be investigated.
• Track distribution advisories for exact fixed kernel versions and confirm the remediated kernel is actually booted after maintenance windows.