From: sashiko-bot@kernel.org
To: "Cong Zhang" <cong.zhang@oss.qualcomm.com>
Cc: "Eugenio Perez" <eperezma@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
virtualization@lists.linux.dev
Subject: Re: [PATCH v2] virtio_blk: use synchronous quiesce in virtblk_freeze_priv()
Date: Sat, 12 Sep 2026 09:04:29 +0000 [thread overview]
Message-ID: <20260912090429.AB9D81F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260912-virtblk_sync_quiesce-v2-1-09a001549b72@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Polling I/O (via `virtblk_poll`) can dereference a freed or NULL `vblk->vqs` because the queue is unfrozen before `vblk->vqs` is freed, and polling paths do not check if the queue is quiesced.
--
commit f53b3954fde7a5b53ac6d49c8006ad87ad21054b
Author: Cong Zhang <cong.zhang@oss.qualcomm.com>
virtio_blk: use synchronous quiesce in virtblk_freeze_priv()
This commit replaces blk_mq_quiesce_queue_nowait() with blk_mq_quiesce_queue()
in virtblk_freeze_priv(). The queue is explicitly quiesced synchronously to
prevent dispatch code from continuing to run and accessing deleted virtqueues.
Link: https://lore.kernel.org/20260911-virtblk_sync_quiesce-v1-1-a883f8f31258@oss.qualcomm.com
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 32bf3ba07a9dc..7a570591e040a 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -1595,7 +1595,7 @@ static int virtblk_freeze_priv(struct virtio_device *vdev)
>
> /* Ensure no requests in virtqueues before deleting vqs. */
> memflags = blk_mq_freeze_queue(q);
> - blk_mq_quiesce_queue_nowait(q);
> + blk_mq_quiesce_queue(q);
> blk_mq_unfreeze_queue(q, memflags);
[Severity: High]
This isn't a bug introduced by this patch, but does unfreezing the queue here
leave polling I/O exposed to a use-after-free or NULL pointer dereference?
If virtio_blk is configured with poll_queues > 0, polling is enabled. Because
the queue is explicitly unfrozen before vblk->vqs is freed later in
virtblk_freeze_priv(), a userspace process can submit new polled requests
(e.g., via preadv2(RWF_HIPRI)).
These requests can successfully enter the queue and increment q_usage_counter.
The process can then call blk_rq_poll(), which bypasses the standard dispatch
path and directly calls the driver's poll callback (virtblk_poll()).
Since polling paths do not check if the queue is quiesced, virtblk_poll() can
calculate a pointer using the now-freed vblk->vqs and attempt to acquire a
spinlock, resulting in an immediate use-after-free or NULL pointer
dereference:
virtblk_freeze_priv() {
...
blk_mq_unfreeze_queue(q, memflags); // Queue unfrozen
virtio_reset_device(vdev);
flush_work(&vblk->config_work);
vdev->config->del_vqs(vdev);
kfree(vblk->vqs); // vqs freed
vblk->vqs = NULL;
...
}
virtblk_poll() {
...
struct virtio_blk_vq *vq = get_virtio_blk_vq(hctx);
...
spin_lock_irqsave(&vq->lock, flags); // UAF / NULL dereference
...
}
This patch aims to fix a structurally identical race in the dispatch path by
using a synchronous quiesce, but it appears to leave this polling race
unresolved.
>
> /* Ensure we don't receive any more interrupts */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260912-virtblk_sync_quiesce-v2-1-09a001549b72@oss.qualcomm.com?part=1
next prev parent reply other threads:[~2026-09-12 9:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-12 8:52 [PATCH v2] virtio_blk: use synchronous quiesce in virtblk_freeze_priv() Cong Zhang
2026-09-12 9:04 ` sashiko-bot [this message]
2026-09-12 9:09 ` Michael S. Tsirkin
2026-09-12 9:19 ` Cong Zhang
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=20260912090429.AB9D81F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=cong.zhang@oss.qualcomm.com \
--cc=eperezma@redhat.com \
--cc=mst@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=virtualization@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.