From: sashiko-bot@kernel.org
To: "Jasper Wise" <jaspwise@amazon.co.uk>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi: virtio_scsi: set DRIVER_OK before registering the SCSI host
Date: Thu, 13 Aug 2026 09:02:31 +0000 [thread overview]
Message-ID: <20260813090231.AF1BF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260813084405.610322-1-jaspwise@amazon.co.uk>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Preexisting Use-After-Free in the SCSI error handler or block layer when `scsi_add_host()` fails after a concurrent sysfs scan.
--
--- Patch [1]: [PATCH] scsi: virtio_scsi: set DRIVER_OK before registering the SCSI host ---
commit 58209fcc60c7b4a593d3a3456eb44d5ff9a7db6b
Author: Jasper Wise <jaspwise@amazon.co.uk>
scsi: virtio_scsi: set DRIVER_OK before registering the SCSI host
This commit alters the virtio-scsi device initialization to set DRIVER_OK
prior to calling scsi_add_host(). It also updates the probe error handling
to ensure the device is correctly reset if host registration fails.
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
[ ... ]
> @@ -991,7 +991,7 @@ static int virtscsi_probe(struct virtio_device *vdev)
> return 0;
>
> scsi_add_host_failed:
> - vdev->config->del_vqs(vdev);
> + virtscsi_remove_vqs(vdev);
[Severity: High]
This is a pre-existing issue, but could this error path trigger a
use-after-free if scsi_add_host() fails?
When scsi_add_host() runs, it calls scsi_add_host_with_dma(), which exposes
the scan sysfs attribute via device_add():
drivers/scsi/hosts.c:scsi_add_host_with_dma() {
...
error = device_add(&shost->shost_dev);
if (error)
goto out_del_gendev;
...
}
If a subsequent initialization step inside device_add() fails,
scsi_add_host() will unwind and return an error.
If a concurrent write to the scan attribute happens before the unwind,
scsi_scan_host_selected() can create child SCSI targets. Because
scsi_add_host() does not reap these concurrently created children on its
error path, they remain orphaned.
If we proceed to free the virtqueues here via virtscsi_remove_vqs(),
could a later SCSI error handler invocation such as virtscsi_abort()
dereference the freed virtqueues?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813084405.610322-1-jaspwise@amazon.co.uk?part=1
prev parent reply other threads:[~2026-08-13 9:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 8:44 [PATCH] scsi: virtio_scsi: set DRIVER_OK before registering the SCSI host Jasper Wise
2026-08-13 9:02 ` sashiko-bot [this message]
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=20260813090231.AF1BF1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=jaspwise@amazon.co.uk \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.