Skip to main content
VulnerabilityPublished Updated

CVE-2026-64114: Linux kernel · Improper Input Validation

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in bc20dbd48c26e743f7e0845020c11ed2ce8b15ee : patch Linux kernel soon.

Data as of 26 Oct 2026, 17:30 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 3% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in bc20dbd48c26e743f7e0845020c11ed2ce8b15ee, bbe0be67de296176e7243c76e3d9f02f6ae9ff0b, 7725cd3b471740fd23d25ed1da722c671fb2a5d3 +5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 19 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < bc20dbd48c26e743f7e0845020c11ed2ce8b15ee
Fixed in
  • bc20dbd48c26e743f7e0845020c11ed2ce8b15ee
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < bbe0be67de296176e7243c76e3d9f02f6ae9ff0b
Fixed in
  • bbe0be67de296176e7243c76e3d9f02f6ae9ff0b
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 7725cd3b471740fd23d25ed1da722c671fb2a5d3
Fixed in
  • 7725cd3b471740fd23d25ed1da722c671fb2a5d3
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 1065b9efa4126df559b03a849c139ecfae92cd25
Fixed in
  • 1065b9efa4126df559b03a849c139ecfae92cd25
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 915fab69823a14c170dbaa3b41978768e0fe62fc
Fixed in
  • 915fab69823a14c170dbaa3b41978768e0fe62fc
LinuxLinuxAffected
  • ≥ 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2, < 145e9afa5b905229b4788bb72c3255f5a5f77508
Fixed in
  • 145e9afa5b905229b4788bb72c3255f5a5f77508

Description

In 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.

References

Community reviews

Loading reviews…