[PATCH] nvmet-fcloop: fail LS request synchronously when remote port is gone
Hannes Reinecke
hare at suse.de
Mon Sep 21 02:00:38 PDT 2026
On 9/20/26 6:38 PM, Nguyen Ngoc Thang wrote:
> fcloop_t2h_ls_req() handles a missing remoteport by queueing the request
> on tport->ls_list and completing it with -ECONNREFUSED from a work item.
>
> nvmet_fc_delete_assoc_work() sends the Disconnect Association LS this
> way. When it runs during nvmet_fc_unregister_targetport(), the work is
> queued after flush_workqueue() has started, so it is not waited for.
> nvmet_fc_free_pending_reqs() then frees the still-pending lsop and the
> late work item calls lsreq->done() on freed memory:
>
> BUG: KASAN: slab-use-after-free in fcloop_rport_lsrqst_work+0x242/0x2e0
> Workqueue: nvmet-wq fcloop_tport_lsrqst_work
> Allocated by nvmet_fc_xmt_disconnect_assoc
> Freed by nvmet_fc_free_pending_reqs
> nvmet_fc_unregister_targetport
> fcloop_delete_target_port
>
> Return -ECONNREFUSED directly instead. __nvmet_fc_send_ls_req() unwinds
> and nvmet_fc_xmt_disconnect_assoc() frees the lsop, so no completion is
> left outstanding.
>
> Reported-by: syzbot+77955102efac681ec73b at syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=77955102efac681ec73b
> Fixes: bbccbf791e6f ("nvmet-fc: free pending reqs on tgtport unregister")
> Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999 at gmail.com>
> ---
> drivers/nvme/target/fcloop.c | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/nvme/target/fcloop.c b/drivers/nvme/target/fcloop.c
> index b63af3b643a6..9f9fb40f8a97 100644
> --- a/drivers/nvme/target/fcloop.c
> +++ b/drivers/nvme/target/fcloop.c
> @@ -456,21 +456,18 @@ fcloop_t2h_ls_req(struct nvmet_fc_target_port *targetport, void *hosthandle,
> * 1:1 tgtport vs remoteport
> */
>
> + /*
> + * Fail synchronously: an async completion can run after
> + * nvmet_fc_unregister_targetport() has freed the pending lsreq.
> + */
> + if (!tport->remoteport)
> + return -ECONNREFUSED;
> +
> tls_req = kmem_cache_alloc(lsreq_cache, GFP_KERNEL);
> if (!tls_req)
> return -ENOMEM;
> tls_req->lsreq = lsreq;
> INIT_LIST_HEAD(&tls_req->ls_list);
> -
> - if (!tport->remoteport) {
> - tls_req->status = -ECONNREFUSED;
> - spin_lock(&tport->lock);
> - list_add_tail(&tls_req->ls_list, &tport->ls_list);
> - spin_unlock(&tport->lock);
> - queue_work(nvmet_wq, &tport->ls_work);
> - return ret;
> - }
> -
> tls_req->status = 0;
> ret = nvme_fc_rcv_ls_req(tport->remoteport, &tls_req->ls_rsp,
> lsreq->rqstaddr, lsreq->rqstlen);
Can you create a blktest for this?
Otherwise look good.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare at suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
More information about the Linux-nvme
mailing list