Re: [PATCH v2] dma: at_hdmac: Fix use-after-free by proper tasklet cleanup

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect teardown order in the probe error path leaves the driver vulnerable to Use-After-Free and pool corruption.
- [Low] Unused local variables `chan` and `_chan` are left in `at_dma_remove()`, which will cause compiler warnings.
--

commit 2676b9fc85315dd8a64edbcb2460a143edbcb102
Author: Hongling Zeng <zenghongling@kylinos.cn>

dma: at_hdmac: Fix use-after-free by proper tasklet cleanup
    
This commit fixes a use-after-free vulnerability by properly ordering the
teardown path to free IRQs before killing tasklets and freeing other
resources.

Closes: https://lore.kernel.org/all/20260604073945.54B311F00898@smtp.kernel.org/

> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index e5b30a57c477a..9048b56b082f4 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
[ ... ]
> @@ -2109,6 +2122,8 @@ static int __init at_dma_probe(struct platform_device *pdev)
>  err_memset_pool_create:
>  	dma_pool_destroy(atdma->lli_pool);
>  err_desc_pool_create:
> +	if (atdma->dma_device.channels.next != NULL)
> +		at_dma_cleanup_channels(atdma);
>  	free_irq(platform_get_irq(pdev, 0), atdma);

[Severity: High]
Does this sequence in the probe error path violate the cleanup order mentioned
in the commit message?

The commit message states that free_irq() should happen first, then tasklets
should be killed, and finally other resources should be freed.

In this error path, if probe fails at dma_async_device_register(), we call
dma_pool_destroy() on both pools, then at_dma_cleanup_channels() kills the
tasklets, and free_irq() is called last:

err_dma_async_device_register:
	dma_pool_destroy(atdma->memset_pool);
err_memset_pool_create:
	dma_pool_destroy(atdma->lli_pool);
err_desc_pool_create:
	if (atdma->dma_device.channels.next != NULL)
		at_dma_cleanup_channels(atdma);
	free_irq(platform_get_irq(pdev, 0), atdma);

Could an active IRQ handler still fire and schedule tasklets, causing a
use-after-free on the already-destroyed pool memory?

>  err_irq:
>  	clk_disable_unprepare(atdma->clk);
> @@ -2125,16 +2140,11 @@ static void at_dma_remove(struct platform_device *pdev)
>  		of_dma_controller_free(pdev->dev.of_node);
>  	dma_async_device_unregister(&atdma->dma_device);
>  
> -	dma_pool_destroy(atdma->memset_pool);
> -	dma_pool_destroy(atdma->lli_pool);
>  	free_irq(platform_get_irq(pdev, 0), atdma);

[Severity: Low]
This isn't a bug, but does at_dma_remove() still declare the local variables
chan and _chan after this refactoring?

The loop previously using these variables was moved to
at_dma_cleanup_channels(), so leaving them declared at the top of
at_dma_remove() might cause -Wunused-variable compiler warnings:

static void at_dma_remove(struct platform_device *pdev)
{
	struct at_dma		*atdma = platform_get_drvdata(pdev);
	struct dma_chan		*chan, *_chan;

> +	at_dma_cleanup_channels(atdma);
>  
> -	list_for_each_entry_safe(chan, _chan, &atdma->dma_device.channels,
> -			device_node) {
> -		/* Disable interrupts */
> -		atc_disable_chan_irq(atdma, chan->chan_id);
> -		list_del(&chan->device_node);
> -	}
> +	dma_pool_destroy(atdma->memset_pool);
> +	dma_pool_destroy(atdma->lli_pool);
>  
>  	clk_disable_unprepare(atdma->clk);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604101912.318118-1-zenghongling@kylinos.cn?part=1