From: Takashi Iwai <tiwai@suse.de>
To: "Cássio Gabriel" <cassiogabrielcontato@gmail.com>
Cc: Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+8fa95c41eafbc9d2ff6f@syzkaller.appspotmail.com,
stable@vger.kernel.org
Subject: Re: [PATCH] ALSA: aloop: Fix peer runtime UAF during format-change stop
Date: Fri, 24 Apr 2026 13:14:27 +0200 [thread overview]
Message-ID: <87se8k1ugc.wl-tiwai@suse.de> (raw)
In-Reply-To: <20260423-alsa-aloop-peer-stop-uaf-v1-1-25d8a9745f6c@gmail.com>
On Thu, 23 Apr 2026 05:22:22 +0200,
Cássio Gabriel wrote:
>
> loopback_check_format() may stop the capture side when playback starts
> with parameters that no longer match a running capture stream. Commit
> 826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") moved
> the peer lookup under cable->lock, but the actual snd_pcm_stop() still
> runs after dropping that lock.
>
> A concurrent close can clear the capture entry from cable->streams[] and
> detach or free its runtime while the playback trigger path still holds a
> stale peer substream pointer.
>
> Keep a per-cable count of in-flight peer stops before dropping
> cable->lock, make free_cable() wait for those stops before detaching the
> runtime, and take the peer stream lock around snd_pcm_stop(). This
> preserves the existing behavior while making the peer runtime lifetime
> explicit.
>
> Reported-by: syzbot+8fa95c41eafbc9d2ff6f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=8fa95c41eafbc9d2ff6f
> Fixes: 597603d615d2 ("ALSA: introduce the snd-aloop module for the PCM loopback")
> Cc: stable@vger.kernel.org
> Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
> ---
> sound/drivers/aloop.c | 56 ++++++++++++++++++++++++++++++++++++---------------
> 1 file changed, 40 insertions(+), 16 deletions(-)
>
> diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c
> index aa0d2fcb1a18..a997ee262740 100644
> --- a/sound/drivers/aloop.c
> +++ b/sound/drivers/aloop.c
> @@ -99,6 +99,9 @@ struct loopback_ops {
> struct loopback_cable {
> spinlock_t lock;
> struct loopback_pcm *streams[2];
> + /* in-flight peer stops running outside cable->lock */
> + atomic_t stop_count;
> + wait_queue_head_t stop_wait;
> struct snd_pcm_hardware hw;
> /* flags */
> unsigned int valid;
> @@ -337,10 +340,10 @@ static bool is_access_interleaved(snd_pcm_access_t access)
> static int loopback_check_format(struct loopback_cable *cable, int stream)
> {
> struct loopback_pcm *dpcm_play, *dpcm_capt;
> + struct loopback_pcm *stop_dpcm = NULL;
> struct snd_pcm_runtime *runtime, *cruntime;
> struct loopback_setup *setup;
> struct snd_card *card;
> - bool stop_capture = false;
> int check;
>
> scoped_guard(spinlock_irqsave, &cable->lock) {
> @@ -366,8 +369,11 @@ static int loopback_check_format(struct loopback_cable *cable, int stream)
> return 0;
> if (stream == SNDRV_PCM_STREAM_CAPTURE)
> return -EIO;
> - else if (cruntime->state == SNDRV_PCM_STATE_RUNNING)
> - stop_capture = true;
> + else if (cruntime->state == SNDRV_PCM_STATE_RUNNING) {
> + /* close must not free the peer runtime below */
> + atomic_inc(&cable->stop_count);
> + stop_dpcm = dpcm_capt;
> + }
> }
>
> setup = get_setup(dpcm_play);
> @@ -396,8 +402,18 @@ static int loopback_check_format(struct loopback_cable *cable, int stream)
> }
> }
>
> - if (stop_capture)
> - snd_pcm_stop(dpcm_capt->substream, SNDRV_PCM_STATE_DRAINING);
> + if (stop_dpcm) {
> + struct snd_pcm_substream *stop_substream = stop_dpcm->substream;
> + unsigned long flags;
> +
> + snd_pcm_stream_lock_irqsave_nested(stop_substream, flags);
> + if (stop_substream->runtime && snd_pcm_running(stop_substream))
> + snd_pcm_stop(stop_substream, SNDRV_PCM_STATE_DRAINING);
> + snd_pcm_stream_unlock_irqrestore(stop_substream, flags);
> +
> + if (atomic_dec_and_test(&cable->stop_count))
> + wake_up(&cable->stop_wait);
> + }
Do we need to complicate this handling? IOW, can it be simply be like
below?
if (stop_capture) {
snd_pcm_stop(dpcm_capt->substream, SNDRV_PCM_STATE_DRAINING);
if (atomic_dec_and_test(&cable->stop_count))
wake_up(&cable->stop_wait);
}
thanks,
Takashi
next prev parent reply other threads:[~2026-04-24 11:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 3:22 [PATCH] ALSA: aloop: Fix peer runtime UAF during format-change stop Cássio Gabriel
2026-04-24 11:14 ` Takashi Iwai [this message]
2026-04-24 12:14 ` Cássio Gabriel Monteiro Pires
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=87se8k1ugc.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=cassiogabrielcontato@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=stable@vger.kernel.org \
--cc=syzbot+8fa95c41eafbc9d2ff6f@syzkaller.appspotmail.com \
--cc=tiwai@suse.com \
/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