From: sashiko-bot@kernel.org
To: phucduc.bui@gmail.com
Cc: Frank.Li@kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH 07/11] ASoC: fsl_xcvr: Use guard() for spin locks
Date: Fri, 12 Jun 2026 13:37:22 +0000 [thread overview]
Message-ID: <20260612133723.4BCDB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260612132639.78086-8-phucduc.bui@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The work struct `xcvr->work_rst` can be re-scheduled by the IRQ handler after it is cancelled in `fsl_xcvr_remove()`, leading to a Use-After-Free.
--
commit cd76e5a17f7950836eed0759c4053e72e241e545
Author: bui duc phuc <phucduc.bui@gmail.com>
ASoC: fsl_xcvr: Use guard() for spin locks
Clean up the code using guard() for spin locks. Merely code refactoring,
and no behavior change.
> diff --git a/sound/soc/fsl/fsl_xcvr.c b/sound/soc/fsl/fsl_xcvr.c
> index 6677d3bf36ec2..41d100500534f 100644
> --- a/sound/soc/fsl/fsl_xcvr.c
> +++ b/sound/soc/fsl/fsl_xcvr.c
[ ... ]
> @@ -1448,11 +1445,10 @@ static void reset_rx_work(struct work_struct *work)
[Severity: High]
This is a pre-existing issue, but could this work struct be rescheduled by an
interrupt after it has been cancelled during removal, leading to a
use-after-free?
In fsl_xcvr_remove(), the driver calls cancel_work_sync(&xcvr->work_rst),
but hardware interrupts are not explicitly disabled before devres cleans
up. Because irq0_isr() was registered with devm_request_irq(), the interrupt
handler remains active after fsl_xcvr_remove() returns.
If an interrupt fires in this window, irq0_isr() can call:
if (isr & (FSL_XCVR_IRQ_PREAMBLE_MISMATCH |
...)) {
schedule_work(&xcvr->work_rst);
}
This queues reset_rx_work() on a device structure (xcvr) that devres will soon
free, resulting in a use-after-free when the work queue executes.
> {
> struct fsl_xcvr *xcvr = container_of(work, struct fsl_xcvr, work_rst);
> struct device *dev = &xcvr->pdev->dev;
> - unsigned long lock_flags;
> u32 ext_ctrl;
>
> dev_dbg(dev, "reset rx path\n");
> - spin_lock_irqsave(&xcvr->lock, lock_flags);
> + guard(spinlock_irqsave)(&xcvr->lock);
> regmap_read(xcvr->regmap, FSL_XCVR_EXT_CTRL, &ext_ctrl);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612132639.78086-1-phucduc.bui@gmail.com?part=7
next prev parent reply other threads:[~2026-06-12 13:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 13:26 [PATCH 00/11] ASoC: fsl: Use guard() for mutex & spin locks phucduc.bui
2026-06-12 13:26 ` [PATCH 01/11] ASoC: fsl_asrc: Use guard() for " phucduc.bui
2026-06-12 13:38 ` sashiko-bot
2026-06-12 13:26 ` [PATCH 02/11] ASoC: fsl_audmix: " phucduc.bui
2026-06-12 13:26 ` [PATCH 03/11] ASoC: fsl_easrc: " phucduc.bui
2026-06-12 13:36 ` sashiko-bot
2026-06-12 13:26 ` [PATCH 04/11] ASoC: fsl_esai: " phucduc.bui
2026-06-12 13:26 ` [PATCH 05/11] ASoC: fsl_spdif: " phucduc.bui
2026-06-12 13:38 ` sashiko-bot
2026-06-12 13:26 ` [PATCH 06/11] ASoC: fsl_ssi: Use guard() for mutex locks phucduc.bui
2026-06-12 13:26 ` [PATCH 07/11] ASoC: fsl_xcvr: Use guard() for spin locks phucduc.bui
2026-06-12 13:37 ` sashiko-bot [this message]
2026-06-12 13:26 ` [PATCH 08/11] ASoC: imx-audio-rpmsg: " phucduc.bui
2026-06-12 13:46 ` sashiko-bot
2026-06-12 13:26 ` [PATCH 09/11] ASoC: fsl_rpmsg: Use guard() for mutex & " phucduc.bui
2026-06-12 13:42 ` sashiko-bot
2026-06-12 13:26 ` [PATCH 10/11] ASoC: fsl: mpc5200_dma: Use guard() for " phucduc.bui
2026-06-12 13:44 ` sashiko-bot
2026-06-12 13:26 ` [PATCH 11/11] ASoC: fsl: mpc5200_psc_ac97: Use guard() for mutex locks phucduc.bui
2026-06-12 13:42 ` sashiko-bot
2026-06-12 15:05 ` Mark Brown
2026-06-12 21:42 ` Bui Duc Phuc
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=20260612133723.4BCDB1F000E9@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.