From: sashiko-bot@kernel.org
To: "Tyrel Datwyler" <tyreld@linux.ibm.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 14/20] scsi: ibmvfc: fix UAF and stall in NVMe LS abort callback
Date: Wed, 16 Sep 2026 23:33:12 +0000 [thread overview]
Message-ID: <20260916233313.E50B41F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260916230921.2204729-15-tyreld@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] scsi: ibmvfc: ABA vulnerability in ls_abort due to lockless reallocation
- [Medium] scsi: ibmvfc: target kref leak on H_CLOSED during abort
--
commit 2b161f932735b7864868d34990303d50d9aa8f72
Author: Tyrel Datwyler <tyreld@linux.ibm.com>
scsi: ibmvfc: fix UAF and stall in NVMe LS abort callback
This commit attempts to fix a use-after-free and a blocking stall in
ibmvfc_nvme_ls_abort() by introducing a dedicated async completion callback
and taking the host_lock around the event lookup. It also removes the
blocking wait_for_completion() call on the timeout workqueue.
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc-nvme.c b/drivers/scsi/ibmvscsi/ibmvfc-nvme.c
> index 52e2621a43424..7e18b79ae4ccc 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc-nvme.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc-nvme.c
[ ... ]
> @@ -202,34 +203,35 @@ static void ibmvfc_nvme_ls_abort(struct nvme_fc_local_port *lport,
> {
> struct ibmvfc_host *vhost = lport->private;
> struct ibmvfc_target *tgt = rport->private;
> - struct ibmvfc_event *evt;
> - union ibmvfc_iu rsp;
> + struct ibmvfc_event *evt, *abt_evt;
> unsigned long flags;
> - u16 status = IBMVFC_MAD_CRQ_ERROR;
> +
> + spin_lock_irqsave(&vhost->host->host_lock, flags);
> +
> + /*
> + * If the original LS has already completed naturally, abt_evt will
> + * have been freed back to the pool (evt->free set to 1 under
> + * host_lock by ibmvfc_free_event()). Nothing left to cancel.
> + */
> + abt_evt = ls_abort->private;
> + if (!abt_evt || atomic_read(&abt_evt->free)) {
[Severity: High]
Is this check vulnerable to an ABA problem?
If the original command completes and frees the event, evt->free is set to 1.
If a new command immediately reallocates it, evt->free is set to 0. This
reallocation happens under queue->l_lock, not host_lock.
When this code acquires host_lock and checks atomic_read(&abt_evt->free), it
will read 0 and assume it is still the original command. Could this result
in aborting the new command instead, or dereferencing a stale target pointer
in ibmvfc_init_ls_abort()?
> + spin_unlock_irqrestore(&vhost->host->host_lock, flags);
> + return;
> + }
>
> evt = ibmvfc_get_event(&vhost->crq);
> - if (!vhost->logged_in || !evt)
> + if (!vhost->logged_in || !evt) {
> + spin_unlock_irqrestore(&vhost->host->host_lock, flags);
> return;
> + }
>
> - spin_lock_irqsave(&vhost->host->host_lock, flags);
> kref_get(&tgt->kref);
> - ibmvfc_init_event(evt, ibmvfc_sync_nvme_completion, IBMVFC_MAD_FORMAT);
> - ibmvfc_init_ls_abort(evt, ls_abort);
> - evt->sync_iu = &rsp;
> -
> - if (ibmvfc_send_event(evt, vhost, default_timeout))
> - goto out;
> -
> - spin_unlock_irqrestore(&vhost->host->host_lock, flags);
> + ibmvfc_init_event(evt, ibmvfc_nvme_ls_abort_done, IBMVFC_MAD_FORMAT);
> + ibmvfc_init_ls_abort(evt, abt_evt);
> + evt->tgt = tgt;
>
> - wait_for_completion(&evt->comp);
> - status = be16_to_cpu(rsp.mad_common.status);
> - spin_lock_irqsave(&vhost->host->host_lock, flags);
> - ibmvfc_free_event(evt);
> -out:
> + ibmvfc_send_event(evt, vhost, default_timeout);
[Severity: Medium]
Does ignoring the return value of ibmvfc_send_event() leak the target kref?
We call kref_get(&tgt->kref) before this point and delegate the kref_put()
to the completion callback. However, if ibmvfc_send_event() returns
SCSI_MLQUEUE_HOST_BUSY (which happens when rc == H_CLOSED), it frees the
event internally without executing the callback.
Will this cause the target structure memory to be leaked?
> + spin_unlock_irqrestore(&vhost->host->host_lock, flags);
> - ibmvfc_dbg(vhost, "ls_abort: cancel failed with rc=%x\n", status);
> - kref_put(&tgt->kref, ibmvfc_release_tgt);
> }
>
> static void ibmvfc_nvme_done(struct ibmvfc_event *evt)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260916230921.2204729-1-tyreld@linux.ibm.com?part=14
next prev parent reply other threads:[~2026-09-16 23:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 23:09 [PATCH 00/20] scsi: ibmvfc: Fixes and cleanup for NVMe/FC support Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 01/20] scsi: ibmvfc: initialize evt->tgt for NVMe FCP commands Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 02/20] scsi: ibmvfc: fix trace logging " Tyrel Datwyler
2026-09-16 23:21 ` sashiko-bot
2026-09-16 23:09 ` [PATCH 03/20] scsi: ibmvfc: complete NVMe FCP requests on H_CLOSED send failure Tyrel Datwyler
2026-09-16 23:24 ` sashiko-bot
2026-09-16 23:09 ` [PATCH 04/20] scsi: ibmvfc: defer NVMe local port registration out of atomic context Tyrel Datwyler
2026-09-16 23:27 ` sashiko-bot
2026-09-16 23:09 ` [PATCH 05/20] scsi: ibmvfc: fix uninitialized _done dereference for TMF events on send failure Tyrel Datwyler
2026-09-16 23:33 ` sashiko-bot
2026-09-16 23:09 ` [PATCH 06/20] scsi: ibmvfc: fix uninitialized shwqs in ibmvfc_purge_requests() Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 07/20] scsi: ibmvfc: fix uninitialized status logged on LS abort send failure Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 08/20] scsi: ibmvfc: fix inverted suppress-ABTS capability check in NVMe TMF path Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 09/20] scsi: ibmvfc: fix infinite reset loop on NULL evt in implicit logout path Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 10/20] scsi: ibmvfc: fix u16 overflow of max_cmds in ibmvfc_set_login_info() Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 11/20] scsi: ibmvfc: fix UAF and hang in ibmvfc_cancel_all_mq() on send failure Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 12/20] scsi: ibmvfc: fix data race on tgt->nvme_remote_port Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 13/20] scsi: ibmvfc: make NVMe FCP abort callback asynchronous Tyrel Datwyler
2026-09-16 23:27 ` sashiko-bot
2026-09-16 23:09 ` [PATCH 14/20] scsi: ibmvfc: fix UAF and stall in NVMe LS abort callback Tyrel Datwyler
2026-09-16 23:33 ` sashiko-bot [this message]
2026-09-16 23:09 ` [PATCH 15/20] scsi: ibmvfc: unregister NVMe local port on adapter removal Tyrel Datwyler
2026-09-16 23:39 ` sashiko-bot
2026-09-16 23:09 ` [PATCH 16/20] scsi: ibmvfc: fix NVMe local port leak on fabric link bounce Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 17/20] scsi: ibmvfc: fix TOCTOU race in ibmvfc_nvme_create_queue() on adapter removal Tyrel Datwyler
2026-09-16 23:09 ` [PATCH 18/20] scsi: ibmvfc: fix NVMe sub-queue registration failure disabling SCSI multiqueue Tyrel Datwyler
2026-09-16 23:39 ` sashiko-bot
2026-09-16 23:09 ` [PATCH 19/20] scsi: ibmvfc: fix concurrent SCSI and NVMe discover-targets race dropping targets Tyrel Datwyler
2026-09-16 23:41 ` sashiko-bot
2026-09-16 23:09 ` [PATCH 20/20] scsi: ibmvfc: fix nr_nvme_hw_queues module parameter ignored for NVMe queue sizing Tyrel Datwyler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260916233313.E50B41F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tyreld@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.