From: Richard Patel <ripatel@wii.dev>
To: Charles Keepax <ckeepax@opensource.cirrus.com>
Cc: vkoul@kernel.org, yung-chuan.liao@linux.intel.com,
pierre-louis.bossart@linux.dev, peter.ujfalusi@linux.intel.com,
linux-sound@vger.kernel.org, patches@opensource.cirrus.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] soundwire: intel_auxdevice: Don't disable IRQs before removing children
Date: Sun, 4 Oct 2026 12:29:58 +0000 [thread overview]
Message-ID: <asJGxhij4OzWNYn9@wii.dev> (raw)
In-Reply-To: <20260925154216.3520136-4-ckeepax@opensource.cirrus.com>
On Fri, Sep 25, 2026 at 04:42:16PM +0100, Charles Keepax wrote:
> Currently the auxiliary device for the link disables IRQs before it
> calls sdw_bus_master_delete(). This has the side effect that none
> of the devices on the link can access their own registers whilst
> their remove functions run, because the IRQs are required for bus
> transactions to function.
>
> There appear to be two things that currently block leaving the
> IRQs enabled during peripheral removal. Firstly, the IRQ handler
> iterates through a linked list of all the links, once a link is
> removed the memory pointed at by this linked list is freed, but
> not removed from the linked_list. Secondly, the potential that
> an IRQ runs after the controller itself has been destroyed.
>
> For the first problem add a list_del() for the linked list item,
> note whilst the list itself is contained in the intel_init portion
> of the code, the list remove needs to be attached to the auxiliary
> device for the link, since that owns the memory that the list points
> at. Locking is also required to ensure the IRQ handler runs either
> before or after any additions/removals from the list. A new lock is
> added for this, the shim_lock is used to gate access to the shared
> registers so doesn't feel a super obvious fit for managing the list.
>
> For the second problem utilise the newly added helper that allows
> destroying the peripherals separately, allowing the auxiliary device
> to disable IRQs before running its own cleanup.
I ran into a use-after-free on Samsung Galaxy Book6 (Panther Lake)
the other day. I was going to send a patch adding RCU, then I saw
your patch already added a mutex:
sof-audio-pci-intel-ptl 0000:00:1f.3: SOF firmware and/or topology file not found.
Oops: general protection fault, kernel NULL pointer dereference 0x3c0: 0000 [#1] SMP NOPTI
RIP: 0010:sdw_cdns_irq+0x9/0x1f0 [soundwire_cadence]
Call Trace:
sdw_intel_thread+0x2d/0x50 [soundwire_intel]
hda_dsp_interrupt_thread+0x97/0x320 [snd_sof_intel_hda_generic]
irq_thread_fn+0x23/0x60
irq_thread+0xc7/0x190
I would add 'Fixes: 4a98a6b2fa75 ("soundwire: intel/cadence: merge Soundwire interrupt handlers/threads")' maybe
> @@ -145,8 +155,10 @@ irqreturn_t sdw_intel_thread(int irq, void *dev_id)
> struct sdw_intel_ctx *ctx = dev_id;
> struct sdw_intel_link_res *link;
>
> + mutex_lock(&ctx->link_lock);
> list_for_each_entry(link, &ctx->link_list, list)
> sdw_cdns_irq(irq, link->cdns);
> + mutex_unlock(&ctx->link_lock);
>
> return IRQ_HANDLED;
> }
I don't understand the code very well, but isn't there a second UAF
with the ctx object getting freed? kfree(ctx) in sdw_intel_exit()
runs well before the IRQ is unregistered.
-- Richard
next prev parent reply other threads:[~2026-10-04 12:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 15:42 [PATCH v2 0/3] Allow SoundWire devices to communicate during remove Charles Keepax
2026-09-25 15:42 ` [PATCH v2 1/3] soundwire: bus: Don't unassign dev_num before unregistering device Charles Keepax
2026-10-03 8:18 ` Vinod Koul
2026-10-05 9:08 ` Charles Keepax
2026-09-25 15:42 ` [PATCH v2 2/3] soundwire: bus: Expose a helper to remove devices from the bus Charles Keepax
2026-09-25 15:42 ` [PATCH v2 3/3] soundwire: intel_auxdevice: Don't disable IRQs before removing children Charles Keepax
2026-09-26 15:55 ` Pierre-Louis Bossart
2026-09-28 8:39 ` Charles Keepax
2026-09-29 8:34 ` Pierre-Louis Bossart
2026-09-29 12:40 ` Charles Keepax
2026-09-29 18:31 ` Pierre-Louis Bossart
2026-10-04 12:29 ` Richard Patel [this message]
2026-10-05 10:32 ` Charles Keepax
2026-09-29 18:34 ` [PATCH v2 0/3] Allow SoundWire devices to communicate during remove Pierre-Louis Bossart
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=asJGxhij4OzWNYn9@wii.dev \
--to=ripatel@wii.dev \
--cc=ckeepax@opensource.cirrus.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.dev \
--cc=vkoul@kernel.org \
--cc=yung-chuan.liao@linux.intel.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
all inboxes | Powered by JetHome®