CVE-2026-64535: Linux kernel · nvmet-tcp: Fix potential UAF when ddgst mismatch
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 9.8 Critical · fixed in e091ff83d962f9ed00d9bd70443676de9fe98bdc : patch Linux kernel as a priority.
Data as of 26 Oct 2026, 15:59 UTC
- EPSS
- 0.5% chance of exploitation in 30 days – higher than 45% 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 can 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 e091ff83d962f9ed00d9bd70443676de9fe98bdc, dfb902462bca478f050224ec7a7195aafa7643b1, dbbd07d0a7020b80f6a7028e561908f7b83b3d5a +6
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 27 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– |
Description
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.
References
- git.kernel.org/stable/c/dfb902462bca478f050224ec7a7195aafa7643b1 (opens in a new tab)
- git.kernel.org/stable/c/7e558308eba14c8136cb1e615f0c850f76d1fc0a (opens in a new tab)
- git.kernel.org/stable/c/96fe2513df590e74b04253a45089cae75569570e (opens in a new tab)
- git.kernel.org/stable/c/e091ff83d962f9ed00d9bd70443676de9fe98bdc (opens in a new tab)
- git.kernel.org/stable/c/6f9442983a3e4227afd1c83a5251ddbca585ea21 (opens in a new tab)
- git.kernel.org/stable/c/088ee46c18d99baef453afd74181dd40ade044ad (opens in a new tab)
- git.kernel.org/stable/c/dbbd07d0a7020b80f6a7028e561908f7b83b3d5a (opens in a new tab)