CVE-2026-64071

Source
https://cve.org/CVERecord?id=CVE-2026-64071
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64071.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-64071
Downstream
Published
2026-07-19T15:39:47.162Z
Modified
2026-07-21T03:47:53.066728939Z
Summary
nvme-pci: fix use-after-free in nvme_free_host_mem()
Details

In the Linux kernel, the following vulnerability has been resolved:

nvme-pci: fix use-after-free in nvmefreehost_mem()

nvmefreehostmem() frees dev->hmbsgt via dmafreenoncontiguous() but never clears the pointer afterward. This leads to a use-after-free if nvmefreehost_mem() is called twice in the same error path.

This can happen during nvmeprobe() when nvmesetuphostmem() succeeds in allocating the HMB (setting dev->hmbsgt) but nvmesethostmem() fails with an I/O error:

nvmesetuphostmem() nvmeallochostmemsingle() -> sets dev->hmbsgt nvmesethostmem() -> fails with -EIO nvmefreehostmem() -> frees hmb_sgt, but does NOT NULL it return error

nvmeprobe() error path: nvmefreehostmem() -> dev->hmb_sgt is stale, use-after-free

The second call dereferences the freed sgt, causing a NULL pointer dereference in iommudmafreenoncontiguous() when it accesses sgt->sgl->dmaaddress (the backing memory has been freed and zeroed).

This is reproducible on Thunderbolt-attached NVMe devices (e.g., OWC Envoy Express behind a Dell WD22TB4 dock) where the device intermittently returns I/O errors during HMB setup due to PCIe link instability.

BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:iommudmafreenoncontiguous+0x22/0x80 Call Trace: <TASK> dmafreenoncontiguous+0x3b/0x130 nvmefreehostmem+0x30/0xf0 [nvme] nvmeprobe.cold+0xcc/0x275 [nvme] localpciprobe+0x43/0xa0 pcideviceprobe+0xeea/0x290 reallyprobe+0xf9/0x3b0 __driverprobedevice+0x8b/0x170 driverprobedevice+0x24/0xd0 __driverattachasynchelper+0x6b/0x110 asyncrunentryfn+0x37/0x170 processonework+0x1ac/0x3d0 workerthread+0x1b8/0x360 kthread+0xf7/0x130 retfromfork+0x2d8/0x3a0 retfromforkasm+0x1a/0x30 </TASK>

Fix this by setting dev->hmb_sgt to NULL after freeing it, so the second call takes the multi-descriptor path which safely handles the already-cleaned-up state.

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64071.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
63a5c7a4b4c49ad86c362e9f555e6f343804ee1d
Fixed
9525e3a6fbb1d126a22ab2ee86ddea25af581a7c
Fixed
7c89f474005d8377525d2991930b7432ee193a52
Fixed
b35a13036755c5803168a7cb93bc66035c3e65b8

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64071.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
6.13.0
Fixed
6.18.34
Type
ECOSYSTEM
Events
Introduced
6.19.0
Fixed
7.0.11

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-64071.json"