Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Inverted devres teardown order in stm32_dma_probe error path causes a Use-After-Free of the DMA channel name. -- commit 7119ae3e70ddf3efdd1474a7d8b5fbb1ec66bf04 Author: Frank Li <[email protected]> dmaengine: vchan: add vchan_chan_name() to get channel device name This commit introduces the vchan_chan_name() helper to obtain the DMA channel device name. It updates various drivers to use this helper instead of directly accessing dma_chan::dev, ensuring they remain unaffected by upcoming struct member renames. [ ... ] > 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 it possible this exposes a pre-existing use-after-free of the DMA channel name in the probe error path? The dynamically allocated name from vchan_chan_name() is passed to devm_request_irq(), binding the IRQ action's name pointer to the string. If stm32_dma_probe() fails later (for example, if of_dma_controller_register() fails), it jumps to the error label: err_unregister: dma_async_device_unregister(dd); clk_free: clk_disable_unprepare(dmadev->clk); Calling dma_async_device_unregister() here manually frees the DMA channels and their associated kobject names. However, because the IRQs were requested using devm_request_irq(), they remain active and are not freed until later when the probe function returns and devres unwinds. Could this inverted teardown sequence create a window where the IRQ subsystem holds a dangling pointer to the freed name string, potentially leading to memory corruption or a kernel oops if /proc/interrupts is read? [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
