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.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64071.json",
"cna_assigner": "Linux"
}