[PATCH] nvmet: pci-epf: fix use-after-free in nvmet_pci_epf_exec_iod_work()

[PATCH] nvmet: pci-epf: fix use-after-free in nvmet_pci_epf_exec_iod_work()

[Shin'ichiro Kawasaki]

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 reading iod->data_len and iod->dma_dir into local variables
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.

Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver")
Cc: stable@vger.kernel.org
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
---
 drivers/nvme/target/pci-epf.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
index 4e9db96ebfec..05044a110169 100644
--- a/drivers/nvme/target/pci-epf.c
+++ b/drivers/nvme/target/pci-epf.c
@@ -1594,6 +1594,8 @@ static void nvmet_pci_epf_exec_iod_work(struct work_struct *work)
 	struct nvmet_pci_epf_iod *iod =
 		container_of(work, struct nvmet_pci_epf_iod, work);
 	struct nvmet_req *req = &iod->req;
+	size_t data_len;
+	int dma_dir;
 	int ret;
 
 	if (!iod->ctrl->link_up) {
@@ -1638,6 +1640,13 @@ static void nvmet_pci_epf_exec_iod_work(struct work_struct *work)
 		}
 	}
 
+	/*
+	 * Hold iod fields since iod might be freed when it does not have data
+	 * to transfer.
+	 */
+	data_len = iod->data_len;
+	dma_dir = iod->dma_dir;
+
 	req->execute(req);
 
 	/*
@@ -1645,7 +1654,7 @@ static void nvmet_pci_epf_exec_iod_work(struct work_struct *work)
 	 * finishes, nvmet_pci_epf_queue_response() will complete the command
 	 * directly. No need to wait for the completion in this case.
 	 */
-	if (!iod->data_len || iod->dma_dir != DMA_TO_DEVICE)
+	if (!data_len || dma_dir != DMA_TO_DEVICE)
 		return;
 
 	wait_for_completion(&iod->done);
-- 
2.55.0

Re: [PATCH] nvmet: pci-epf: fix use-after-free in nvmet_pci_epf_exec_iod_work()

[Damien Le Moal]

On 7/13/26 13:32, Shin'ichiro Kawasaki wrote:
> 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]

Looks good, but I would do it like this to simplify:

diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
index 4e9db96ebfec..485ce759391a 100644
--- a/drivers/nvme/target/pci-epf.c
+++ b/drivers/nvme/target/pci-epf.c
@@ -1594,6 +1594,7 @@ static void nvmet_pci_epf_exec_iod_work(struct
work_struct *work)
        struct nvmet_pci_epf_iod *iod =
                container_of(work, struct nvmet_pci_epf_iod, work);
        struct nvmet_req *req = &iod->req;
+       bool no_wait;
        int ret;

        if (!iod->ctrl->link_up) {
@@ -1638,14 +1639,16 @@ static void nvmet_pci_epf_exec_iod_work(struct
work_struct *work)
                }
        }

-       req->execute(req);
-
        /*
         * If we do not have data to transfer after the command execution
         * finishes, nvmet_pci_epf_queue_response() will complete the command
         * directly. No need to wait for the completion in this case.
         */
-       if (!iod->data_len || iod->dma_dir != DMA_TO_DEVICE)
+       no_wait = !iod->data_len || iod->dma_dir != DMA_TO_DEVICE;
+
+       req->execute(req);
+
+       if (no_wait)
                return;

        wait_for_completion(&iod->done);


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] nvmet: pci-epf: fix use-after-free in nvmet_pci_epf_exec_iod_work()

[Shin'ichiro Kawasaki]

On Jul 13, 2026 / 16:28, Damien Le Moal wrote:
> On 7/13/26 13:32, Shin'ichiro Kawasaki wrote:
> > 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]
> 
> Looks good, but I would do it like this to simplify:

(snip)

Thanks. Will reflect the suggested change in v2.