Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but there is a 
preexisting Use-After-Free of the channel name string in the IRQ handler 
registration on the probe error path.
--

commit 33984ca85ddf2f8f41c22000aad40c8fceb5f946
Author: Frank Li <[email protected]>

dmaengine: vchan: add vchan_chan_name() to get channel device name

Introduce vchan_chan_name() to obtain the DMA channel device name.
Use a dedicated helper instead of directly accessing dma_chan::dev
so callers remain unaffected by an upcoming rename of the struct member.

[ ... ]

> diff --git a/drivers/dma/stm32/stm32-dma.c b/drivers/dma/stm32/stm32-dma.c
> index d3ad78562a140..3e8151e2ad75a 100644
> --- a/drivers/dma/stm32/stm32-dma.c
> +++ b/drivers/dma/stm32/stm32-dma.c
> @@ -1668,7 +1668,7 @@ static int stm32_dma_probe(struct platform_device *pdev)
>  
>               ret = devm_request_irq(&pdev->dev, chan->irq,
>                                      stm32_dma_chan_irq, 0,
> -                                    dev_name(chan2dev(chan)), chan);
> +                                    vchan_chan_name(&chan->vchan), chan);

[Severity: High]
This isn't a bug introduced by this patch, but is there a preexisting
Use-After-Free of the channel name string in the IRQ handler registration on
the probe error path?

In stm32_dma_probe(), the driver successfully registers the DMA device using
dma_async_device_register(), then iteratively allocates devres-managed IRQs
using devm_request_irq() with the channel name pointer from vchan_chan_name().

If a subsequent operation fails (e.g. of_dma_controller_register()), the error
handling path manually calls dma_async_device_unregister(dd). This frees the
DMA device and its dynamically allocated channel name string immediately.

However, the devres-managed IRQs remain active until the probe function returns
and devres cleanup runs. During this window, the IRQ subsystem holds a dangling
pointer to the freed channel name.

Could this race window be triggered by unprivileged users concurrently reading
/proc/interrupts, or if an interrupt fires during this time?

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=1

Reply via email to