CVE-2026-64071

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix use-after-free in nvme_free_host_mem()<br /> <br /> nvme_free_host_mem() frees dev-&gt;hmb_sgt via dma_free_noncontiguous()<br /> but never clears the pointer afterward. This leads to a use-after-free<br /> if nvme_free_host_mem() is called twice in the same error path.<br /> <br /> This can happen during nvme_probe() when nvme_setup_host_mem() succeeds<br /> in allocating the HMB (setting dev-&gt;hmb_sgt) but nvme_set_host_mem()<br /> fails with an I/O error:<br /> <br /> nvme_setup_host_mem()<br /> nvme_alloc_host_mem_single() -&gt; sets dev-&gt;hmb_sgt<br /> nvme_set_host_mem() -&gt; fails with -EIO<br /> nvme_free_host_mem() -&gt; frees hmb_sgt, but does NOT NULL it<br /> return error<br /> <br /> nvme_probe() error path:<br /> nvme_free_host_mem() -&gt; dev-&gt;hmb_sgt is stale, use-after-free<br /> <br /> The second call dereferences the freed sgt, causing a NULL pointer<br /> dereference in iommu_dma_free_noncontiguous() when it accesses<br /> sgt-&gt;sgl-&gt;dma_address (the backing memory has been freed and zeroed).<br /> <br /> This is reproducible on Thunderbolt-attached NVMe devices (e.g., OWC<br /> Envoy Express behind a Dell WD22TB4 dock) where the device intermittently<br /> returns I/O errors during HMB setup due to PCIe link instability.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> RIP: 0010:iommu_dma_free_noncontiguous+0x22/0x80<br /> Call Trace:<br /> <br /> dma_free_noncontiguous+0x3b/0x130<br /> nvme_free_host_mem+0x30/0xf0 [nvme]<br /> nvme_probe.cold+0xcc/0x275 [nvme]<br /> local_pci_probe+0x43/0xa0<br /> pci_device_probe+0xeea/0x290<br /> really_probe+0xf9/0x3b0<br /> __driver_probe_device+0x8b/0x170<br /> driver_probe_device+0x24/0xd0<br /> __driver_attach_async_helper+0x6b/0x110<br /> async_run_entry_fn+0x37/0x170<br /> process_one_work+0x1ac/0x3d0<br /> worker_thread+0x1b8/0x360<br /> kthread+0xf7/0x130<br /> ret_from_fork+0x2d8/0x3a0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Fix this by setting dev-&gt;hmb_sgt to NULL after freeing it, so the<br /> second call takes the multi-descriptor path which safely handles the<br /> already-cleaned-up state.