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 v5 09/11] ALSA: virtio: prioritize staged capture period work
Date: Wed, 28 Oct 2026 00:03:31 +0000 [thread overview]
Message-ID: <sashiko-outbox-187248@kernel.org> (raw)
In-Reply-To: <20261027234334.32551-10-mynameisjune111@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ALSA: virtio: UAF/NULL deref in virtsnd_pcm_period_elapsed() after open fail
--
commit fc06cf9505ce3c738b1bc2bf02c081ba34868b30
Author: Joonho Lee <mynameisjune111@gmail.com>
ALSA: virtio: prioritize staged capture period work
This commit introduces virtsnd_pcm_schedule_period_elapsed() to queue
elapsed_period work onto system_highpri_wq for staged capture streams while
keeping playback and non-staged streams on the normal workqueue. All ten
producers of elapsed_period work are updated to use this helper.
Link: https://lore.kernel.org/all/rfc-v2-vz-capture-compat-1.b9ab4c1540dc4691@gmail.com/
[ ... ]
> diff --git a/sound/virtio/virtio_pcm_ops.c b/sound/virtio/virtio_pcm_ops.c
> index 85e7576903d56..d50924b792f65 100644
> --- a/sound/virtio/virtio_pcm_ops.c
> +++ b/sound/virtio/virtio_pcm_ops.c
> @@ -232,7 +232,7 @@ virtsnd_pcm_pause_restart_fail(struct virtio_pcm_substream *vss,
> VIRTSND_PCM_PAUSE_RESTART_RESET_REQUIRED;
> }
> if (notify_xrun)
> - schedule_work(&vss->elapsed_period);
> + virtsnd_pcm_schedule_period_elapsed(vss);
> vss->substream->runtime->stop_operating = true;
> }
[Severity: High]
Can queuing vss->elapsed_period onto system_highpri_wq from
virtsnd_pcm_pause_restart_fail() cause a NULL pointer dereference or
use-after-free of substream->runtime if virtsnd_pcm_open() fails?
During virtsnd_pcm_open(), the driver calls virtsnd_pcm_sync_stop(), which
dispatches to virtsnd_pcm_pause_restart_sync_stop() when pause-restart is
enabled:
sound/virtio/virtio_pcm_ops.c:virtsnd_pcm_pause_restart_sync_stop() {
scoped_guard(spinlock_irqsave, &vss->lock) {
vss->xfer_enabled = false;
vss->stopped = true;
state = vss->pause_restart_state;
}
cancel_work_sync(&vss->elapsed_period);
if (state == VIRTSND_PCM_PAUSE_RESTART_RESET_REQUIRED ||
virtsnd_pcm_pause_restart_transitioning(state)) {
virtsnd_pcm_pause_restart_fail(vss, true);
...
return -EIO;
}
...
}
Although virtsnd_pcm_pause_restart_sync_stop() cancels vss->elapsed_period
at the beginning, all of its error paths call
virtsnd_pcm_pause_restart_fail(). Whenever vss->xfer_xrun was false (for
example, after a prior session failed in virtsnd_pcm_dev_set_params() ->
virtsnd_pcm_pause_restart_send() or left the stream in
VIRTSND_PCM_PAUSE_RESTART_PREPARED without starting), notify_xrun is true
and virtsnd_pcm_pause_restart_fail() re-queues vss->elapsed_period onto
system_highpri_wq after cancel_work_sync() has already completed.
When virtsnd_pcm_open() returns this error to snd_pcm_open_substream(),
substream->hw_opened is still 0, so snd_pcm_release_substream() skips
virtsnd_pcm_close() and immediately calls snd_pcm_detach_substream(),
freeing substream->runtime and setting substream->runtime = NULL without
holding pcm_stream_lock.
When virtsnd_pcm_period_elapsed() then runs on system_highpri_wq for a
staged capture stream, it calls snd_pcm_running(substream) before checking
whether substream->runtime is NULL:
sound/virtio/virtio_pcm.c:virtsnd_pcm_period_elapsed() {
...
guard(pcm_stream_lock_irqsave)(substream);
if (!snd_pcm_running(substream)) {
scoped_guard(spinlock_irqsave, &vss->lock) {
runtime = substream->runtime;
paused_xrun = runtime &&
...
}
Since snd_pcm_running(substream) unconditionally reads
substream->runtime->state, can this dereference a freed or NULL
substream->runtime, or leave vss->elapsed_period pending after
virtsnd_pcm_sync_stop() returns?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261027234334.32551-1-mynameisjune111@gmail.com?part=9
next prev parent reply other threads:[~2026-10-28 0:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 23:43 [PATCH v5 00/11] ALSA: virtio: staged capture and dsnoop recovery Joonho Lee
2026-10-27 23:43 ` [PATCH v5 01/11] ALSA: virtio: Propagate PCM send failures through ACK Joonho Lee
2026-10-28 0:09 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 02/11] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-10-28 0:18 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 03/11] ALSA: virtio: Retain queued messages through device reset Joonho Lee
2026-10-28 0:15 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 04/11] ALSA: virtio: Keep PCM DMA buffers alive through device ownership Joonho Lee
2026-10-27 23:59 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 05/11] ALSA: virtio: Keep control payloads alive through DMA completion Joonho Lee
2026-10-27 23:55 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 06/11] ALSA: virtio: wait through signals for PCM teardown Joonho Lee
2026-10-28 0:07 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 07/11] ALSA: virtio: stage VZ capture and restart paused streams Joonho Lee
2026-10-28 0:19 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 08/11] ALSA: virtio: account staged capture reads before RX refill Joonho Lee
2026-10-27 23:53 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 09/11] ALSA: virtio: prioritize staged capture period work Joonho Lee
2026-10-28 0:03 ` sashiko-bot [this message]
2026-10-27 23:43 ` [PATCH v5 10/11] ALSA: pcm: mark stop-threshold accesses for capture policy sampling Joonho Lee
2026-10-27 23:48 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 11/11] ALSA: virtio-snd: fix dsnoop capture with staged buffers Joonho Lee
2026-10-28 0:13 ` 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-187248@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.