From: sashiko-bot@kernel.org
To: "Joonho Lee" <mynameisjune111@gmail.com>, linux-sound@vger.kernel.org
Cc: virtualization@lists.linux.dev,
"Michael S. Tsirkin" <mst@redhat.com>,
"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH v13 03/12] ALSA: virtio: Retain queued messages through device reset
Date: Tue, 03 Nov 2026 09:25:48 +0000 [thread overview]
Message-ID: <sashiko-outbox-194954@kernel.org> (raw)
In-Reply-To: <20261103080821.16983-4-mynameisjune111@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ALSA: virtio: NULL deref in virtsnd_disable_event_vq() on probe failure
--
commit dbe53b6c2e9b3ca5c54f2da85fde0a3fdaa123b3
Author: Joonho Lee <mynameisjune111@gmail.com>
ALSA: virtio: Retain queued messages through device reset
This commit retains the control queue through snd_card_free() during device
teardown, detaches remaining virtqueue buffers after device reset, and
protects virtqueue callbacks under their respective queue locks.
> diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
> index 6f35276416fed..aec4959c973ca 100644
> --- a/sound/virtio/virtio_card.c
> +++ b/sound/virtio/virtio_card.c
[ ... ]
> @@ -174,8 +188,9 @@ static void virtsnd_disable_event_vq(struct virtio_snd *snd)
> struct virtio_snd_event *event;
> u32 length;
>
> + guard(spinlock_irqsave)(&queue->lock);
> + snd->event_vq_enabled = false;
> if (queue->vqueue) {
> - guard(spinlock_irqsave)(&queue->lock);
> virtqueue_disable_cb(queue->vqueue);
> while ((event = virtqueue_get_buf(queue->vqueue, &length)))
> virtsnd_event_dispatch(snd, event);
[Severity: High]
Can virtsnd_disable_event_vq() dereference a NULL pointer when cleaning up
after a failure in virtsnd_probe()?
In virtsnd_probe(), virtsnd_find_vqs() populates the event virtqueue with
buffers while snd->event_vq_enabled is still false, and virtio_device_ready()
marks the device live before virtsnd_build_devs() creates the ALSA objects:
sound/virtio/virtio_card.c:virtsnd_probe() {
...
rc = virtsnd_find_vqs(snd);
if (rc)
goto on_exit;
virtio_device_ready(vdev);
rc = virtsnd_build_devs(snd);
if (rc)
goto on_exit;
virtsnd_enable_event_vq(snd);
on_exit:
if (rc)
virtsnd_remove(vdev);
...
}
Because VIRTIO_CONFIG_S_DRIVER_OK is set before virtsnd_build_devs(), the
device can place events into the event queue while virtsnd_build_devs() is
running. With this change, virtsnd_event_notify_cb() sees
!snd->event_vq_enabled and leaves those events in the ring.
If virtsnd_build_devs() fails before virtsnd_enable_event_vq() is reached
(for example, after virtsnd_kctl_parse_cfg() sets snd->nkctls and allocates
snd->kctls, but before virtsnd_kctl_build_devs() populates each kctl->kctl),
virtsnd_probe() calls virtsnd_remove() -> virtsnd_disable_event_vq().
Since virtsnd_disable_event_vq() unconditionally drains queue->vqueue and
calls virtsnd_event_dispatch() without checking whether snd->event_vq_enabled
was true, dispatching a pending event against partially initialized state
(such as passing &kctl->kctl->id to snd_ctl_notify() in virtsnd_kctl_event()
when kctl->kctl is NULL) will dereference a NULL pointer.
Should virtsnd_disable_event_vq() only drain and dispatch events if
snd->event_vq_enabled was previously true?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261103080821.16983-1-mynameisjune111@gmail.com?part=3
next prev parent reply other threads:[~2026-11-03 9:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 8:08 [PATCH v13 00/12] ALSA: virtio: staged capture recovery and PCM RESET synchronization Joonho Lee
2026-11-03 8:08 ` [PATCH v13 01/12] ALSA: virtio: Propagate PCM send failures through ACK Joonho Lee
2026-11-03 8:33 ` sashiko-bot
2026-11-03 8:08 ` [PATCH v13 02/12] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-11-03 8:55 ` sashiko-bot
2026-11-03 8:08 ` [PATCH v13 03/12] ALSA: virtio: Retain queued messages through device reset Joonho Lee
2026-11-03 9:25 ` sashiko-bot [this message]
2026-11-03 8:08 ` [PATCH v13 04/12] ALSA: virtio: Keep PCM DMA buffers alive through device ownership Joonho Lee
2026-11-03 9:49 ` sashiko-bot
2026-11-03 8:08 ` [PATCH v13 05/12] ALSA: virtio: Keep control payloads alive through DMA completion Joonho Lee
2026-11-03 9:56 ` sashiko-bot
2026-11-03 8:08 ` [PATCH v13 06/12] ALSA: virtio: wait through signals for PCM teardown Joonho Lee
2026-11-03 10:15 ` sashiko-bot
2026-11-03 8:08 ` [PATCH v13 07/12] ALSA: pcm: mark stop-threshold accesses for capture policy sampling Joonho Lee
2026-11-03 10:17 ` sashiko-bot
2026-11-03 8:08 ` [PATCH v13 08/12] ALSA: pcm: report partial progress under the stream lock Joonho Lee
2026-11-03 10:20 ` sashiko-bot
2026-11-03 8:08 ` [PATCH v13 09/12] ALSA: pcm: add an optional reset operation " Joonho Lee
2026-11-03 10:27 ` sashiko-bot
2026-11-03 8:08 ` [PATCH v13 10/12] ALSA: virtio: add staged capture and serialize PCM lifecycle accounting Joonho Lee
2026-11-03 11:05 ` sashiko-bot
2026-11-03 8:08 ` [PATCH v13 11/12] ALSA: virtio: prioritize staged capture period work Joonho Lee
2026-11-03 11:09 ` sashiko-bot
2026-11-03 8:08 ` [PATCH v13 12/12] docs: describe virtio-sound capture options Joonho Lee
2026-11-03 11:27 ` sashiko-bot
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=sashiko-outbox-194954@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eperezma@redhat.com \
--cc=linux-sound@vger.kernel.org \
--cc=mst@redhat.com \
--cc=mynameisjune111@gmail.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.