PT-2026-85628 · Linux · Linux

CVE-2026-80787

·

Published

2026-09-04

·

Updated

2026-09-04

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
nvmet: pci-epf: fix use-after-free in nvmet pci epf exec iod work()
nvmet pci epf exec iod work() 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->data len and iod->dma dir 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, nvmet pci epf queue response() calls nvmet pci epf complete iod() directly, which can free the iod before it reads iod->data len and iod->dma dir, resulting in the KFENCE use-after- free:
BUG: KFENCE: use-after-free read in nvmet pci epf exec iod work+0x288/0x798 [nvmet pci epf]
Use-after-free read at 0x00000000fdfa6d03 (in kfence-#63): nvmet pci epf exec iod work+0x288/0x798 [nvmet pci epf] process one work+0x15c/0x4f0 worker thread+0x18c/0x30c kthread+0x130/0x140 ret from fork+0x10/0x20
kfence-#63: 0x00000000e3de0e71-0x00000000c938ad62, size=712, cache=kmalloc-1k
allocated by task 10 on cpu 0 at 73.995480s (0.005122s ago): mempool kmalloc+0x1c/0x28 mempool alloc noprof+0x40/0x9c nvmet pci epf poll sqs work+0xd4/0x344 [nvmet pci epf] process one work+0x15c/0x4f0 worker thread+0x18c/0x30c kthread+0x130/0x140 ret from fork+0x10/0x20
freed by task 131 on cpu 3 at 73.995521s (0.008385s ago): mempool kfree+0x10/0x20 mempool free+0x44/0x64 nvmet pci epf free iod+0x88/0x98 [nvmet pci epf] nvmet pci epf cq work+0xfc/0x280 [nvmet pci epf] process one work+0x15c/0x4f0 worker thread+0x18c/0x30c kthread+0x130/0x140 ret from fork+0x10/0x20
Fix this by referring to iod->data len and iod->dma dir 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, nvmet pci epf queue response() signals iod->done instead of freeing the iod, so the iod stays valid.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-80787

Affected Products

Linux