PT-2026-85628 · Linux · Linux
CVE-2026-80787
·
Publicado
2026-09-04
·
Atualizado
2026-09-04
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux