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
Affected Products
Linux