CVE-2026-64114: ipv4: raw: reject IP_HDRINCL packets with ihl < 5

Published Jul 19, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

ipv4: raw: reject IPHDRINCL packets with ihl < 5

rawsendhdrinc() validates that the caller-supplied IPv4 header fits within the message length:

iphlen = iph->ihl 4; err = -EINVAL; if (iphlen > length) goto errorfree;

if (iphlen >= sizeof(iph)) { / fix up saddr, totlen, id, csum, transportheader / }

It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to iplocalout() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ahoutput() in particular subtracts sizeof(struct iphdr) from topiph->ihl 4 and passes the (signed-int-negative, then cast to sizet) result to memcpy(), producing an OOB access of length close to SIZEMAX and a host kernel panic.

An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path.

Reject "iphlen < sizeof(iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to.

Once this lands, the "if (iphlen >= sizeof(iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it.

Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl.

Reachability: the malformed packet source is any caller with CAPNETRAW, including an unprivileged process in a user+net namespace on a kernel with CONFIGUSERNS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAPNETADMIN can install that state and policy in its netns. Loopback bypasses xfrmoutput, so the trigger uses a real netdev.

Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpyorig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NETADMIN on a stock distro kernel.

Affected Software

17 affected components
Linux Linux kernel
Linux Linux kernel>=2.6.12.1<5.10.258
Linux Linux kernel>=5.11<5.15.209
Linux Linux kernel>=5.16<6.1.175
Linux Linux kernel>=6.2<6.6.142
Linux Linux kernel>=6.7<6.12.92
Linux Linux kernel>=6.13<6.18.34
Linux Linux kernel>=6.19<7.0.11
Linux Linux kernel=2.6.12
Linux Linux kernel=2.6.12-rc2
Linux Linux kernel=2.6.12-rc3
Linux Linux kernel=2.6.12-rc4
Linux Linux kernel=2.6.12-rc5
Linux Linux kernel=7.1-rc1
Linux Linux kernel=7.1-rc2
Linux Linux kernel=7.1-rc3
Linux Linux kernel=7.1-rc4

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Modify IPv4 raw socket handling to reject packets where the IPv4 header length field results in ihl < 5 (i.e., reject "iphlen < sizeof(*iph)" alongside the existing "iphlen > length" check), preventing malformed IPv4 headers from being accepted and processed.

    Linux kernel Reject "iphlen < sizeof(*iph)" (i.e., reject malformed IPv4 headers with ihl < 5) = enabled
  2. Compensating control

    If running in an environment where xfrm output could be bypassed (e.g., loopback bypasses xfrm_output per the text), ensure outbound/egress IPsec/XFRM policies (AH policy) are correctly configured/matched so malformed packets do not re-enter the IP stack without the expected policy checks.

Event History

Jul 19, 2026
CVE Published
via MITRE·03:40 PM
Data Sourced
via MITRE·03:40 PM
DescriptionSeverity
Data Sourced
via NVD·04:17 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-64114?

CVE-2026-64114 has a high severity rating of 7.8 according to the CVSS 3.1 scoring system.

2

How do I fix CVE-2026-64114?

To fix CVE-2026-64114, update your Linux kernel to the latest version where this vulnerability has been patched.

3

What type of vulnerability is CVE-2026-64114?

CVE-2026-64114 is a vulnerability in the Linux kernel related to the validation of IPv4 header lengths.

4

What systems are affected by CVE-2026-64114?

CVE-2026-64114 affects systems running specific versions of the Linux kernel that allow IP_HDRINCL packets with invalid header lengths.

5

Is CVE-2026-64114 a denial of service vulnerability?

While CVE-2026-64114's description implies improper handling of packets, it is categorized with a high CVSS score, indicating serious potential impact.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203