Re: [PATCH] dmaengine: st_fdma: fix potential use-after-free in vchan tasklets

[Frank Li <Frank.li@oss.nxp.com>]

On Sat, Sep 12, 2026 at 11:46:29PM +0800, Guangshuo Li wrote:
> st_fdma_probe() allocates the channel array with devm_kcalloc() and
> initializes an embedded virt-dma tasklet for each st_fdma_chan through
> vchan_init().
>
> The interrupt handler calls vchan_cookie_complete() or
> vchan_cyclic_callback(), which may schedule the tasklet. However,
> st_fdma_remove() only frees the IRQ and does not kill already scheduled
> tasklets.
>
> devm_free_irq() prevents new interrupt handlers from running and waits
> for an in-flight handler to finish, but it does not flush a tasklet
> that was scheduled by a previous interrupt. Since fdev->chans is
> devm-managed, the channel array is released after the remove callback
> returns.
>
> This leaves the following possible race:
>
>   CPU0 (driver removal)                 CPU1 (IRQ / softirq)
>   ---------------------                 --------------------
>                                         st_fdma_irq_handler()
>                                           vchan_cookie_complete()
>                                             tasklet_schedule()
>                                         return
>                                         <tasklet pending>
>
>   st_fdma_remove()
>     devm_free_irq()
>     ...
>     return
>
>   devres cleanup
>     ...
>     kfree(fdev->chans)                  // FREE
>                                         vchan_complete()
>                                           vc = from_tasklet(...)
>                                           spin_lock_irq(&vc->lock)
>                                                        // USE -> UAF
>
> The pending tasklet is embedded in the devm-allocated st_fdma_chan.
> Once fdev->chans is released, the tasklet and the virt_dma_chan
> containing it point into freed memory. A later vchan_complete() can
> therefore dereference the freed channel and cause a potential
> use-after-free.
>
> Kill all vchan tasklets after freeing the IRQ. This prevents new
> interrupt handlers from scheduling them and waits for any tasklet that
> is already pending or running before the channel storage can be
> released.
>
> This issue was found by manual code inspection.
>
> Fixes: 6b4cd727eaf15 ("dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---

I prefer defer all tasklet tear down fix patches after

https://lore.kernel.org/dmaengine/5ae73ce5-1216-4012-abe0-aba9469ef089@deltatee.com/

Frank

>  drivers/dma/st_fdma.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
> index d9547017f3bd..23071cbf1866 100644
> --- a/drivers/dma/st_fdma.c
> +++ b/drivers/dma/st_fdma.c
> @@ -846,8 +846,13 @@ static int st_fdma_probe(struct platform_device *pdev)
>  static void st_fdma_remove(struct platform_device *pdev)
>  {
>  	struct st_fdma_dev *fdev = platform_get_drvdata(pdev);
> +	int i;
>
>  	devm_free_irq(&pdev->dev, fdev->irq, fdev);
> +
> +	for (i = 0; i < fdev->nr_channels; i++)
> +		tasklet_kill(&fdev->chans[i].vchan.task);
> +
>  	st_slim_rproc_put(fdev->slim_rproc);
>  	of_dma_controller_free(pdev->dev.of_node);
>  }
> --
> 2.43.0
>