From: sashiko-bot@kernel.org
To: phucduc.bui@gmail.com
Cc: Frank.Li@kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH v2 10/11] ASoC: fsl: mpc5200_dma: Use guard() for spin locks
Date: Mon, 15 Jun 2026 09:57:12 +0000 [thread overview]
Message-ID: <20260615095712.F266F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260615093824.115751-11-phucduc.bui@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The `psc_dma` structure is freed in `mpc5200_audio_dma_destroy()` before the ALSA components are unregistered, leading to a use-after-free and locking of freed memory if userspace invokes component operations during module unbind.
--
commit d1f00eba902c807bb72ff7810e5332f8b08165b6
Author: bui duc phuc <phucduc.bui@gmail.com>
ASoC: fsl: mpc5200_dma: Use guard() for spin locks
This commit cleans up the spin lock usage in the mpc5200_dma driver by
converting it to use the scoped_guard() macro.
> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
> index 56e2cf2f727ba..bfedb2dea0b32 100644
> --- a/sound/soc/fsl/mpc5200_dma.c
> +++ b/sound/soc/fsl/mpc5200_dma.c
[ ... ]
> @@ -135,19 +136,18 @@ static int psc_dma_trigger(struct snd_soc_component *component,
> /* Fill up the bestcomm bd queue and enable DMA.
> * This will begin filling the PSC's fifo.
> */
> - spin_lock_irqsave(&psc_dma->lock, flags);
> -
> - if (substream->pstr->stream == SNDRV_PCM_STREAM_CAPTURE)
> - bcom_gen_bd_rx_reset(s->bcom_task);
> - else
> - bcom_gen_bd_tx_reset(s->bcom_task);
> + scoped_guard(spinlock_irqsave, &psc_dma->lock) {
[Severity: High]
This isn't a bug introduced by this patch, but could this code race with
module unbind and dereference a freed psc_dma pointer?
During driver removal, the callbacks (like psc_i2s_of_remove) manually call
mpc5200_audio_dma_destroy(), which frees the psc_dma object and clears the
driver data:
sound/soc/fsl/mpc5200_dma.c:mpc5200_audio_dma_destroy() {
...
kfree(psc_dma);
dev_set_drvdata(&op->dev, NULL);
}
However, the ALSA component is registered via devm_snd_soc_register_component(),
meaning it remains registered and accessible to userspace until the devres
teardown runs after the remove callback returns.
If userspace invokes a PCM operation during this window, ALSA could call
psc_dma_trigger(), which fetches the driver data (now NULL or pointing
to freed memory) and attempts to acquire the lock here using scoped_guard(),
leading to a use-after-free or NULL pointer dereference crash.
> + if (substream->pstr->stream == SNDRV_PCM_STREAM_CAPTURE)
> + bcom_gen_bd_rx_reset(s->bcom_task);
> + else
> + bcom_gen_bd_tx_reset(s->bcom_task);
>
> - for (i = 0; i < runtime->periods; i++)
> - if (!bcom_queue_full(s->bcom_task))
> - psc_dma_bcom_enqueue_next_buffer(s);
> + for (i = 0; i < runtime->periods; i++)
> + if (!bcom_queue_full(s->bcom_task))
> + psc_dma_bcom_enqueue_next_buffer(s);
>
> - bcom_enable(s->bcom_task);
> - spin_unlock_irqrestore(&psc_dma->lock, flags);
> + bcom_enable(s->bcom_task);
> + }
>
> out_8(®s->command, MPC52xx_PSC_RST_ERR_STAT);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615093824.115751-1-phucduc.bui@gmail.com?part=10
next prev parent reply other threads:[~2026-06-15 9:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 9:38 [PATCH v2 00/11] ASoC: fsl: Use guard() for mutex & spin locks phucduc.bui
2026-06-15 9:38 ` [PATCH v2 01/11] ASoC: fsl_asrc: Use guard() for " phucduc.bui
2026-06-15 9:51 ` sashiko-bot
2026-06-15 14:18 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 02/11] ASoC: fsl_audmix: " phucduc.bui
2026-06-15 14:30 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 03/11] ASoC: fsl_easrc: " phucduc.bui
2026-06-15 9:48 ` sashiko-bot
2026-06-15 14:24 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 04/11] ASoC: fsl_esai: " phucduc.bui
2026-06-15 9:52 ` sashiko-bot
2026-06-15 14:15 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 05/11] ASoC: fsl_spdif: " phucduc.bui
2026-06-15 9:52 ` sashiko-bot
2026-06-15 14:17 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 06/11] ASoC: fsl_ssi: Use guard() for mutex locks phucduc.bui
2026-06-15 14:25 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 07/11] ASoC: fsl_xcvr: Use guard() for spin locks phucduc.bui
2026-06-15 9:49 ` sashiko-bot
2026-06-15 14:19 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 08/11] ASoC: imx-audio-rpmsg: " phucduc.bui
2026-06-15 9:51 ` sashiko-bot
2026-06-15 14:17 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 09/11] ASoC: fsl_rpmsg: Use guard() for mutex & " phucduc.bui
2026-06-15 9:59 ` sashiko-bot
2026-06-15 14:12 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 10/11] ASoC: fsl: mpc5200_dma: Use guard() for " phucduc.bui
2026-06-15 9:57 ` sashiko-bot [this message]
2026-06-15 14:14 ` Frank Li
2026-06-15 9:38 ` [PATCH v2 11/11] ASoC: fsl: mpc5200_psc_ac97: Use guard() for mutex locks phucduc.bui
2026-06-15 14:26 ` Frank Li
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=20260615095712.F266F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=imx@lists.linux.dev \
--cc=phucduc.bui@gmail.com \
--cc=sashiko-reviews@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.