From: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
To: vkoul@kernel.org, perex@perex.cz, tiwai@suse.com
Cc: pierre-louis.bossart@linux.dev, linux-sound@vger.kernel.org,
stable@vger.kernel.org
Subject: [PATCH v2 2/4] ALSA: compress: reject buffer geometry change on gapless next_track
Date: Mon, 19 Oct 2026 17:45:31 +0300 [thread overview]
Message-ID: <20261019144533.30665-3-peter.ujfalusi@linux.intel.com> (raw)
In-Reply-To: <20261019144533.30665-1-peter.ujfalusi@linux.intel.com>
snd_compr_set_params() is invoked from the gapless next_track
re-entry path, which calls snd_compr_allocate_buffer() again and lets
buffer_size change while total_bytes_available and
total_bytes_transferred still hold values computed for the previous
buffer. snd_compr_calc_avail() then derives an avail/count value from
those stale counters against the new buffer_size, and
snd_compr_write_data() copy_from_user()s that many bytes into the
new, potentially smaller buffer, overflowing it with user-controlled
length and content.
The buffer is set up once, with the initial SET_PARAMS, and neither the
core nor the DSP expects it to change for a gapless track transition.
Do not call snd_compr_allocate_buffer() on the next_track path and
reject a request that changes the buffer geometry, so that the codec
parameters that the driver receives match the buffer in use.
Fixes: 9727b490e543 ("ALSA: compress: add support for gapless playback")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
---
sound/core/compress_offload.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
index 50301f72579e..d6863336f21c 100644
--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -697,9 +697,19 @@ snd_compr_set_params(struct snd_compr_stream *stream, unsigned long arg)
if (retval)
return retval;
- retval = snd_compr_allocate_buffer(stream, params);
- if (retval)
- return -ENOMEM;
+ if (stream->next_track) {
+ /*
+ * total_bytes_available/transferred still refer to the
+ * current buffer; its geometry must not change.
+ */
+ if (params->buffer.fragment_size != stream->runtime->fragment_size ||
+ params->buffer.fragments != stream->runtime->fragments)
+ return -EINVAL;
+ } else {
+ retval = snd_compr_allocate_buffer(stream, params);
+ if (retval)
+ return retval;
+ }
retval = stream->ops->set_params(stream, params);
if (retval) {
--
2.56.0
next prev parent reply other threads:[~2026-10-19 14:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 14:45 [PATCH v2 0/4] ALSA: compress: fix buffer handling and state validation Peter Ujfalusi
2026-10-19 14:45 ` [PATCH v2 1/4] ALSA: compress: fix buffer leak on failed SET_PARAMS Peter Ujfalusi
2026-10-19 14:45 ` Peter Ujfalusi [this message]
2026-10-19 14:45 ` [PATCH v2 3/4] ALSA: compress: add missing OPEN-state gate to SET_METADATA Peter Ujfalusi
2026-10-19 14:45 ` [PATCH v2 4/4] ALSA: compress: reject restarting an ACTIVE task via origin_seqno Peter Ujfalusi
2026-10-20 8:48 ` [PATCH v2 0/4] ALSA: compress: fix buffer handling and state validation Takashi Iwai
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=20261019144533.30665-3-peter.ujfalusi@linux.intel.com \
--to=peter.ujfalusi@linux.intel.com \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.dev \
--cc=stable@vger.kernel.org \
--cc=tiwai@suse.com \
--cc=vkoul@kernel.org \
/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.