CVE-2026-80787: nvmet: pci-epf: fix use-after-free in nvmet_pci_epf_exec_iod_work()
In the Linux kernel, the following vulnerability has been resolved:
nvmet: pci-epf: fix use-after-free in nvmetpciepfexeciodwork()
nvmetpciepfexeciodwork() submits an I/O command with req->execute() and then waits for the command to complete and transfers the data back to the host. This wait is not needed for commands that do not transfer data from the device to the host. To decide whether that wait is needed, it reads iod->datalen and iod->dmadir after calling req->execute().
However, once req->execute() is called, the command may complete asynchronously on another CPU. For commands that do not require a device-to-host data transfer, nvmetpciepfqueueresponse() calls nvmetpciepfcompleteiod() directly, which can free the iod before it reads iod->datalen and iod->dmadir, resulting in the KFENCE use-after- free:
BUG: KFENCE: use-after-free read in nvmetpciepfexeciodwork+0x288/0x798 [nvmetpciepf]
Use-after-free read at 0x00000000fdfa6d03 (in kfence-#63): nvmetpciepfexeciodwork+0x288/0x798 [nvmetpciepf] processonework+0x15c/0x4f0 workerthread+0x18c/0x30c kthread+0x130/0x140 retfromfork+0x10/0x20
kfence-#63: 0x00000000e3de0e71-0x00000000c938ad62, size=712, cache=kmalloc-1k
allocated by task 10 on cpu 0 at 73.995480s (0.005122s ago): mempoolkmalloc+0x1c/0x28 mempoolallocnoprof+0x40/0x9c nvmetpciepfpollsqswork+0xd4/0x344 [nvmetpciepf] processonework+0x15c/0x4f0 workerthread+0x18c/0x30c kthread+0x130/0x140 retfromfork+0x10/0x20
freed by task 131 on cpu 3 at 73.995521s (0.008385s ago): mempoolkfree+0x10/0x20 mempoolfree+0x44/0x64 nvmetpciepffreeiod+0x88/0x98 [nvmetpciepf] nvmetpciepfcqwork+0xfc/0x280 [nvmetpciepf] processonework+0x15c/0x4f0 workerthread+0x18c/0x30c kthread+0x130/0x140 retfromfork+0x10/0x20
Fix this by referring to iod->datalen and iod->dmadir before calling req->execute(). The remaining iod accesses such as iod->status are only reached on the device-to-host read path. In this case, nvmetpciepfqueueresponse() signals iod->done instead of freeing the iod, so the iod stays valid.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In nvmet_pci_epf_exec_iod_work() (nvmet_pci_epf), read iod->data_len and iod->dma_dir before calling req->execute(). Avoid accessing iod after req->execute() in the code path where the command can complete and the I/O can be freed asynchronously.
Linux kernel nvmet_pci_epf (nvmet: pci-epf) Refactor nvmet_pci_epf_exec_iod_work() to use iod fields before req->execute() = Use-after-free fix: refer to iod->data_len and iod->dma_dir before calling req->execute()
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected code is in the Linux kernel's nvmet_pci_epf component. Exposure requires use of the NVMe target PCI endpoint function path; the provided information does not establish that systems not using this component are affected.
What runtime condition triggers the use-after-free?
The race occurs when nvmet_pci_epf_exec_iod_work() calls req->execute() and the command completes asynchronously before the function reads iod->data_len and iod->dma_dir. It specifically affects commands that do not need a device-to-host data transfer, because the response path can directly complete and free the I/O descriptor.
How can administrators identify a possible occurrence?
A detected occurrence may produce a KFENCE use-after-free report naming nvmet_pci_epf_exec_iod_work in the nvmet_pci_epf module. The supplied example includes a "BUG: KFENCE: use-after-free read" message and a stack trace through process_one_work, worker_thread, and kthread.
What remediation information is available?
The issue is described as resolved in the Linux kernel, and three stable kernel Git commits are provided as references. No affected or fixed kernel version numbers are included in the available data.