Skip to main content
VulnerabilityPublished Updated

CVE-2026-64009: Linux kernel · xfrm: Check for underflow in xfrm_state_mtu

Affects Linux kernelSource CVE Database V5

0

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

Data as of 26 Oct 2026, 10:12 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 fccd685b32df5aaf6bad4381eeda216468e283f0, 8014f70c4e6e5ab101ae3860a614e65e988372e3, 1021d2877b689a648b27815c854557a917122e93 +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
  • ≥ c5c2523893747f88a83376abad310c8ad13f7197, < fccd685b32df5aaf6bad4381eeda216468e283f0
Fixed in
  • fccd685b32df5aaf6bad4381eeda216468e283f0
LinuxLinuxAffected
  • ≥ c5c2523893747f88a83376abad310c8ad13f7197, < 8014f70c4e6e5ab101ae3860a614e65e988372e3
Fixed in
  • 8014f70c4e6e5ab101ae3860a614e65e988372e3
LinuxLinuxAffected
  • ≥ c5c2523893747f88a83376abad310c8ad13f7197, < 1021d2877b689a648b27815c854557a917122e93
Fixed in
  • 1021d2877b689a648b27815c854557a917122e93
LinuxLinuxAffected
  • ≥ c5c2523893747f88a83376abad310c8ad13f7197, < 820e501be8aee4b365d218d83227b314309c5fda
Fixed in
  • 820e501be8aee4b365d218d83227b314309c5fda
LinuxLinuxAffected
  • ≥ c5c2523893747f88a83376abad310c8ad13f7197, < 742b04d0550b0ec89dcbc99537ec88653bd1ad90
Fixed in
  • 742b04d0550b0ec89dcbc99537ec88653bd1ad90
LinuxLinuxAffected
  • ≥ c5c2523893747f88a83376abad310c8ad13f7197, < 82ac903e0b519849647657b8c48d21237ada06a2
Fixed in
  • 82ac903e0b519849647657b8c48d21237ada06a2

Description

In the Linux kernel, the following vulnerability has been resolved: xfrm: Check for underflow in xfrm_state_mtu Leo Lin reported OOB write issue in esp component: xfrm_state_mtu() returns u32 but performs its arithmetic in unsigned modulo-2^32 space using an attacker-influenced "header_len + authsize + net_adj" subtracted from a small "mtu" argument. A nobody user can install an IPv4 ESP tunnel SA with a large authentication key (XFRMA_ALG_AUTH_TRUNC, e.g. hmac(sha512), 64-byte key, 64-byte trunc), configure a small interface MTU (68 bytes), and set XFRMA_TFCPAD to a large value. When a single UDP datagram is then sent through the tunnel, xfrm_state_mtu() underflows to a near-2^32 value, and esp_output() consumes it as a signed int via: padto = min(x->tfcpad, xfrm_state_mtu(x, mtu_cached)) esp.tfclen = padto - skb->len (assigned to int) esp.tfclen ends up negative (e.g. -207). It is sign-extended to size_t when passed to memset() inside esp_output_fill_trailer(), producing a ~16 EB write of zeroes at skb_tail_pointer(skb). KASAN logs it as "Write of size 18446744073709551537 at addr ffff888...". Check for underflow and return 1. This causes the sendmsg attempt to fail with ENETUNREACH.

References

Community reviews

Loading reviews…