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 v10 04/14] ALSA: virtio: Keep PCM DMA buffers alive through device ownership
Date: Fri, 30 Oct 2026 05:56:45 +0000 [thread overview]
Message-ID: <sashiko-outbox-190581@kernel.org> (raw)
In-Reply-To: <20261030052629.27742-5-mynameisjune111@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ALSA: virtio: pause release inflates msg->length in virtsnd_pcm_msg_send()
--
commit ec627d670b7dce9aa5415f6f76196d33998b7e23
Author: Joonho Lee <mynameisjune111@gmail.com>
ALSA: virtio: Keep PCM DMA buffers alive through device ownership
This commit retains references to ALSA's vmalloc buffer pages while I/O
messages are queued (or uses a driver-owned buffer on NOMMU systems), validates
buffer and period boundaries, and clamps device-reported capture completion
lengths to msg->length.
> diff --git a/sound/virtio/virtio_pcm_msg.c b/sound/virtio/virtio_pcm_msg.c
> index 762480363b861..bc2002312a282 100644
> --- a/sound/virtio/virtio_pcm_msg.c
> +++ b/sound/virtio/virtio_pcm_msg.c
[ ... ]
> @@ -363,15 +546,48 @@ static void virtsnd_pcm_msg_complete(struct virtio_pcm_msg *msg,
> * the hw_ptr value is unconditionally advanced.
> */
> guard(spinlock)(&vss->lock);
> +#ifndef CONFIG_MMU
> + if (vss->direction == SNDRV_PCM_STREAM_CAPTURE &&
> + vss->xfer_enabled && written_bytes > sizeof(msg->status)) {
> + struct snd_pcm_runtime *runtime =
> + vss->substream ? vss->substream->runtime : NULL;
> + size_t reported_bytes = written_bytes - sizeof(msg->status);
> + size_t data_bytes = min_t(size_t, reported_bytes, msg->length);
> +
> + if (!runtime || !runtime->dma_area || !vss->owned_dma_area ||
> + msg->data_offset > runtime->dma_bytes ||
> + data_bytes > runtime->dma_bytes - msg->data_offset ||
> + msg->data_offset > vss->owned_dma_bytes ||
> + data_bytes > vss->owned_dma_bytes - msg->data_offset)
> + dev_err_ratelimited(&vss->snd->vdev->dev,
> + "SID %u: invalid capture buffer for I/O message\n",
> + vss->sid);
> + else
> + memcpy(runtime->dma_area + msg->data_offset,
> + vss->owned_dma_area + msg->data_offset, data_bytes);
> + }
> +#endif
> + if (vss->direction == SNDRV_PCM_STREAM_CAPTURE &&
> + written_bytes > sizeof(msg->status) &&
> + written_bytes - sizeof(msg->status) > msg->length)
> + dev_err_ratelimited(&vss->snd->vdev->dev,
> + "SID %u: capture length exceeds I/O message capacity\n",
> + vss->sid);
> /*
> * If the capture substream returned an incorrect status, then just
> - * increase the hw_ptr by the message size.
> + * increase the hw_ptr by the message size. Clamp valid capture lengths to
> + * the actual SG payload capacity before accounting them.
> */
> if (vss->direction == SNDRV_PCM_STREAM_PLAYBACK ||
> - written_bytes <= sizeof(msg->status))
> + written_bytes <= sizeof(msg->status)) {
> vss->hw_ptr += msg->length;
> - else
> - vss->hw_ptr += written_bytes - sizeof(msg->status);
> + } else {
> + size_t data_bytes = min_t(size_t,
> + written_bytes - sizeof(msg->status),
> + msg->length);
> +
> + vss->hw_ptr += data_bytes;
> + }
[Severity: High]
Can SNDRV_PCM_TRIGGER_PAUSE_RELEASE on a capture substream inflate msg->length
beyond period_bytes in virtsnd_pcm_msg_send(), bypassing the new clamp in
virtsnd_pcm_msg_complete() and advancing vss->hw_ptr out of bounds?
In sound/virtio/virtio_pcm_ops.c, virtsnd_pcm_trigger() handles both
SNDRV_PCM_TRIGGER_START and SNDRV_PCM_TRIGGER_PAUSE_RELEASE by submitting the
entire buffer on capture substreams:
sound/virtio/virtio_pcm_ops.c:virtsnd_pcm_trigger() {
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
...
if (vss->direction == SNDRV_PCM_STREAM_CAPTURE)
rc = virtsnd_pcm_msg_send(vss, 0, vss->buffer_bytes);
}
When a capture stream is paused with SNDRV_PCM_TRIGGER_PAUSE_PUSH, the driver
sends VIRTIO_SND_R_PCM_STOP rather than VIRTIO_SND_R_PCM_RELEASE, so uncompleted
RX messages remain queued in the virtqueue with msg->length == period_bytes.
When SNDRV_PCM_TRIGGER_PAUSE_RELEASE subsequently calls
virtsnd_pcm_msg_send(vss, 0, vss->buffer_bytes), the loop adds n to msg->length
unconditionally for every period:
sound/virtio/virtio_pcm_msg.c:virtsnd_pcm_msg_send() {
n = period_bytes - (offset % period_bytes);
if (n > bytes)
n = bytes;
msg->length += n;
if (msg->length == period_bytes) {
...
}
For messages already queued in the virtqueue, msg->length becomes
2 * period_bytes (or (K + 1) * period_bytes after K pause/release cycles), and
for any partially acknowledged message (0 < msg->length < period_bytes),
msg->length is incremented past period_bytes without ever matching
msg->length == period_bytes to be re-queued.
In virtsnd_pcm_msg_complete(), clamping data_bytes to msg->length then permits
oversized device completions up to the inflated msg->length rather than the
single-period SG payload capacity (copying across adjacent periods on NOMMU and
advancing vss->hw_ptr by multiple periods). Likewise, if the stream is released
and pending RX descriptors complete with written_bytes <= sizeof(msg->status),
vss->hw_ptr += msg->length advances vss->hw_ptr by a multiple of period_bytes,
where the single subtraction of vss->buffer_bytes can leave
vss->hw_ptr >= vss->buffer_bytes.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261030052629.27742-1-mynameisjune111@gmail.com?part=4
next prev parent reply other threads:[~2026-10-30 5:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-30 5:26 [PATCH v10 00/14] ALSA: virtio: staged capture recovery and PCM RESET synchronization Joonho Lee
2026-10-30 5:26 ` [PATCH v10 01/14] ALSA: virtio: Propagate PCM send failures through ACK Joonho Lee
2026-10-30 5:26 ` [PATCH v10 02/14] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-10-30 5:26 ` [PATCH v10 03/14] ALSA: virtio: Retain queued messages through device reset Joonho Lee
2026-10-30 5:26 ` [PATCH v10 04/14] ALSA: virtio: Keep PCM DMA buffers alive through device ownership Joonho Lee
2026-10-30 5:56 ` sashiko-bot [this message]
2026-10-30 5:26 ` [PATCH v10 05/14] ALSA: virtio: Keep control payloads alive through DMA completion Joonho Lee
2026-10-30 5:26 ` [PATCH v10 06/14] ALSA: virtio: wait through signals for PCM teardown Joonho Lee
2026-10-30 5:26 ` [PATCH v10 07/14] ALSA: pcm: mark stop-threshold accesses for capture policy sampling Joonho Lee
2026-10-30 5:26 ` [PATCH v10 08/14] ALSA: pcm: report partial progress under the stream lock Joonho Lee
2026-10-30 5:26 ` [PATCH v10 09/14] ALSA: virtio: add staged capture accounting and lifecycle recovery Joonho Lee
2026-10-30 5:26 ` [PATCH v10 10/14] ALSA: virtio: prioritize staged capture period work Joonho Lee
2026-10-30 5:26 ` [PATCH v10 11/14] docs: describe virtio-sound capture options Joonho Lee
2026-10-30 5:26 ` [PATCH v10 12/14] ALSA: pcm: add an optional reset operation under the stream lock Joonho Lee
2026-10-30 5:54 ` sashiko-bot
2026-10-30 5:26 ` [PATCH v10 13/14] ALSA: virtio: synchronize staged capture accounting during RESET Joonho Lee
2026-10-30 5:26 ` [PATCH v10 14/14] ALSA: virtio: rebase ordinary capture accounting on RESET Joonho Lee
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-190581@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox