Re: [PATCH v6 11/23] dmaengine: ste_dma40: Fix DMA registration unwind

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dmaengine: ste_dma40: tasklet UAF on devm_add_action_or_reset failure
--

commit 9ae706f948ab2a5c18bdce25be150382cc3a9c26
Author: Linus Walleij <linusw@kernel.org>

dmaengine: ste_dma40: Fix DMA registration unwind

This commit adds tasklet cleanup actions to the DMAengine registration devres
group. It aims to ensure tasklets are drained before freeing probe resources
on registration failure.

Closes: https://lore.kernel.org/dmaengine/20260819225215.5EA2F1F000E9@smtp.kernel.org/

> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 36f4cbd4da364..87b5f1d97ac23 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c

[ ... ]

> @@ -3088,6 +3100,11 @@ static int __init d40_dmaengine_init(struct d40_base *base,
>  
>  	d40_ops_init(base, &base->dma_slave);
>  
> +	err = devm_add_action_or_reset(base->dev, d40_kill_tasklets,
> +				       &base->dma_slave);
> +	if (err)
> +		goto exit;
> +

[Severity: High]
If devm_add_action_or_reset() fails here, it will immediately execute
d40_kill_tasklets(). Because the device interrupt was enabled earlier in
the probe routine via enable_irq(), could an interrupt fire immediately
after this premature cleanup and reschedule the tasklet?

>  	err = dmaenginem_async_device_register(&base->dma_slave);
>  
>  	if (err) {

[ ... ]

> @@ -3852,20 +3881,33 @@ static int __init d40_probe(struct platform_device *pdev)

[ ... ]

>  	dev_info(base->dev, "initialized\n");
>  	return 0;
>  
> + release_dmaenginem:
> +	if (irq_requested) {
> +		free_irq(base->irq, base);
> +		irq_requested = false;
> +	}
> +	devres_release_group(dev, dmaenginem_reg_group);

[Severity: High]
If we reach this error path because devm_add_action_or_reset() failed,
the tasklet cleanup action was never registered.

Since free_irq() is called here but there is no subsequent tasklet drain,
does this leave any tasklet that was rescheduled after the initial failure
still pending?

Could this result in a use-after-free when the tasklet executes on the
memory freed during the destroy_cache path?

>   destroy_cache:
>  	if (base->lcla_pool.dma_addr)
>  		dma_unmap_single(base->dev, base->lcla_pool.dma_addr,

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260924-dma40-fixes-v6-0-fdb6755020a2@kernel.org?part=11