CVE-2026-64009: Linux kernel · xfrm: Check for underflow in xfrm_state_mtu
Affects Linux kernelSource CVE Database V5
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
- 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:HExploitation evidence
Disclosed: evidence found.
CVE published 19 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by 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
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
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
- git.kernel.org/stable/c/8014f70c4e6e5ab101ae3860a614e65e988372e3 (opens in a new tab)
- git.kernel.org/stable/c/1021d2877b689a648b27815c854557a917122e93 (opens in a new tab)
- git.kernel.org/stable/c/2a41b1b31c61c52b972278ce1732a1443f5e89ed (opens in a new tab)
- git.kernel.org/stable/c/fccd685b32df5aaf6bad4381eeda216468e283f0 (opens in a new tab)
- git.kernel.org/stable/c/820e501be8aee4b365d218d83227b314309c5fda (opens in a new tab)
- git.kernel.org/stable/c/82ac903e0b519849647657b8c48d21237ada06a2 (opens in a new tab)
- git.kernel.org/stable/c/3db50ceeacb52806d8fe86fb1dfe944df0b9f789 (opens in a new tab)
- git.kernel.org/stable/c/742b04d0550b0ec89dcbc99537ec88653bd1ad90 (opens in a new tab)