Re: [PATCH v3 1/4] dmaengine: vchan: add vchan_chan_name() to get channel device name

[sashiko-bot@kernel.org]

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 <Frank.Li@nxp.com>

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/20260904-dma-chan_dev-rename-v3-0-685601b0b788@nxp.com?part=1