Re: [PATCH 18/26] sh: maple: introduce callback_mutex in maple_device
Dmitry Torokhov <[email protected]> Sat, 4 Jul 2026 16:50:04 -0700
| Newsgroups | org.kernel.vger.linux-sh,org.infradead.lists.linux-mtd,org.kernel.vger.linux-input,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi Florian, On Sat, Jul 04, 2026 at 05:48:16PM +0200, Florian Fuchs wrote: > Hi Dmitry, > > On 03 Jul 22:57, Dmitry Torokhov wrote: > > The Maple bus core invokes client callbacks asynchronously from a > > workqueue (maple_dma_handler). If a device is removed (or closed) while > > a callback is in flight, it can lead to UAF bugs if the driver's private > > data is freed. > > > > Introduce callback_mutex in struct maple_device to synchronize > > callback registration/modification and callback invocation. ... > > Thank you so much for your efforts. I can confirm sashikos finding in my > test (that I saw later), Thank you for giving the series a spin! > that this patch hangs the bus if a VMU memcard > is inserted. So that the peripherals don't work anymore after insertion > of the memcard. With a last log like: > Dreamcast_visual_memory 3:01.E: VMU at (3, 1) is busy Yes, indeed, I overlooked the vmu-flash use case. I will introduce a lockless way of setting up the callback and a wrapper that takes the lock and that should solve the deadlock in vmu-flash driver. I wonder if you had a chance top try out the preceding patches and if they worked for you? If they do and you can add your tested-by I should be able to pick up at least the input patches that do not need maple core changes... Thanks. -- Dmitry