CVE-2026-64114
HighIn the Linux kernel, the following vulnerability has been resolved: ipv4: raw: reject IP_HDRINCL packets with ihl < 5 raw_send_hdrinc() validates that the caller-supplied IPv4 header fits within the message length: iphlen = iph->ihl * 4; err = -EINVAL; if (iphlen > length) goto error_free; if (iphlen >= sizeof(*iph)) { /* fix up saddr, tot_len, id, csum, transport_header */ } 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 __ip_local_out() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ah_output() in particular subtracts sizeof(struct iphdr) from top_iph->ihl * 4 and passes the (signed-int-negative, then cast to size_t) result to memcpy(), producing an OOB access of length close to SIZE_MAX 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 CAP_NET_RAW, including an unprivileged process in a user+net namespace on a kernel with CONFIG_USER_NS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAP_NET_ADMIN can install that state and policy in its netns. Loopback bypasses xfrm_output, so the trigger uses a real netdev. Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpy_orig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NET_ADMIN on a stock distro kernel.
CVSS 3.1 score
7.8
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weakness type
CWE-125CVE-2026-64114 is a Out-of-bounds Read vulnerability
What is Out-of-bounds Read?
The product reads data past the end or before the beginning of the intended buffer. Learn more on MITRE CWE
Affected versions
Linux kernel versions
2.6.12
and later are affected. Fixed in
5.10.258,
5.15.209,
6.1.175,
6.6.142,
6.12.92,
6.18.34,
7.0.11,
7.1
and their respective stable series.
References
8 total-
Patch
-
Patch
-
Patch
-
Patch
-
Patch
Frequently asked questions
-
What is CVE-2026-64114?
CVE-2026-64114 is a High severity Linux kernel vulnerability with a CVSS score of 7.8 out of 10 , classified as an Out-of-bounds Read flaw (CWE-125) . It affects Linux kernel versions from 2.6.12 onward and has been patched in 5.10.258, 5.15.209, 6.1.175 and others. CVE-2026-64114 has not been confirmed as actively exploited and is not listed in the CISA KEV catalog.
-
What is the CVSS score for CVE-2026-64114?
CVE-2026-64114 has a CVSS score of 7.8 out of 10, rated High severity (CVSS 3.1). The vector string is
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. -
Is there a patch available for CVE-2026-64114?
Yes. CVE-2026-64114 has been patched. Fixed versions include 5.10.258, 5.15.209, 6.1.175 and others. If you are running Linux kernel 2.6.12 or later up to the fix versions, apply the relevant patch for your kernel branch.
-
Is CVE-2026-64114 actively exploited?
No. CVE-2026-64114 has not been confirmed as actively exploited. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.