Re: [PATCH v4 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] Use-After-Free of DMA channel name in probe error path due to devm/manual cleanup mismatch
--

commit 6477701933e50dc5df4ddb73cea43b46ef1b83f8
Author: Frank Li <Frank.Li@nxp.com>

    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);
>  		if (ret) {
>  			dev_err(&pdev->dev,
>  				"request_irq failed with err %d channel %d\n",

[Severity: High]
This is a pre-existing issue, but in drivers/dma/stm32/stm32-dma.c at
stm32_dma_probe(), devm_request_irq() stores the dynamically allocated DMA
channel name (vchan_chan_name()) as the IRQ name.

If a subsequent initialization step fails, such as a failure in
of_dma_controller_register(), the code jumps to err_unregister:

drivers/dma/stm32/stm32-dma.c:stm32_dma_probe() {
    ...
err_unregister:
	dma_async_device_unregister(dd);
    ...
}

Because dma_async_device_unregister() is called manually, it frees the DMA
device and its associated channel name string immediately. However, since the
IRQ is managed by devm, its cleanup is deferred until devres runs after probe
returns.

Could this create a use-after-free window where the IRQ subsystem retains a
dangling pointer to the freed string? If an interrupt fires or if a user
reads /proc/interrupts concurrently during this window, could this lead to an
oops or memory corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-dma-chan_dev-rename-v4-0-d8fb6892a70f@nxp.com?part=1