Re: [PATCH] dmaengine: fsl-dpaa2-qdma: fix ppriv memory leaks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] Double free of DMA pools (`fd_pool`, `fl_pool`, `sdd_pool`) during driver removal if channels were previously used.
- [High] Incorrect teardown sequence in `dpaa2_qdma_remove()` destroys hardware state and channel resources before unregistering the DMA device.
- [High] Missing `tasklet_kill()` leads to Use-After-Free on the tasklet structures during driver removal.
- [High] Race condition in `dpaa2_qdma_remove()` leading to Use-After-Free in concurrent DPIO notifications.
--

commit 7bbc2b15c0a3c76af93c56c1e6c4036a65094cf2
Author: Guangshuo Li <lgs201920130244@gmail.com>

dmaengine: fsl-dpaa2-qdma: fix ppriv memory leaks

dpaa2_qdma_setup() allocates priv->ppriv separately from priv, but the
allocation is not released on all teardown paths. This commit frees
priv->ppriv on setup failures and during driver removal.

> diff --git a/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c b/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
> index bf771251264d9..0f0fe0291a06f 100644
> --- a/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
> +++ b/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
[ ... ]
> @@ -787,6 +790,7 @@ static void dpaa2_qdma_remove(struct fsl_mc_device *ls_dev)

[Severity: High]
This is a pre-existing issue, but is there a risk of a use-after-free
in the DPIO hardware notification callback during unbind?

Earlier in dpaa2_qdma_remove(), the DPIO store memory is freed:

    dpaa2_dpmai_store_free(priv);
    dpaa2_dpdmai_dpio_free(priv);

If a hardware notification triggers dpaa2_qdma_fqdan_cb() concurrently
between these two calls, it will heavily access the freed ppriv->store
memory. Should the DPIO service be deregistered before the memory it
depends on is destroyed?

>  	dpaa2_dpdmai_free_channels(dpaa2_qdma);

[Severity: High]
This isn't a bug introduced by this patch, but is it possible for
dpaa2_dpdmai_free_channels() to cause a double free of the DMA pools here?

When a client releases a DMA channel, dpaa2_qdma_free_chan_resources()
destroys the pools but leaves the pointers intact:

drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:dpaa2_qdma_free_chan_resources() {
    ...
    dma_pool_destroy(dpaa2_chan->fd_pool);
    dma_pool_destroy(dpaa2_chan->fl_pool);
    dma_pool_destroy(dpaa2_chan->sdd_pool);
    ...
}

If the driver is later unbound, dpaa2_qdma_remove() unconditionally calls
dpaa2_dpdmai_free_channels(), which iterates over the channels and calls
dma_pool_destroy() on these same pointers again. Could this lead to a
panic or memory corruption in the SLUB allocator?

>  
>  	dma_async_device_unregister(&dpaa2_qdma->dma_dev);

[Severity: High]
This is a pre-existing issue, but does this teardown sequence destroy
hardware state and channel resources while the device is still exposed to
clients?

Because dma_async_device_unregister() is called after
dpaa2_dpdmai_free_channels(), the DMA device is still registered with the
DMA core during hardware teardown. Couldn't concurrent clients still submit
operations or request channels, attempting to access already-destroyed pools
or freed portals?

> +	kfree(priv->ppriv);
>  	kfree(priv);
>  	kfree(dpaa2_qdma);

[Severity: High]
This isn't a bug introduced by this patch, but does freeing dpaa2_qdma
here cause a use-after-free for pending tasklets?

The driver initializes a tasklet for each channel during setup:

drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c:dpaa2_dpdmai_init_channels() {
    ...
    vchan_init(&dpaa2_chan->vchan, &dpaa2_qdma->dma_dev);
    ...
}

During removal, kfree(dpaa2_qdma) frees the structure containing these
channels and their embedded tasklets, but tasklet_kill() is never called.
If a tasklet is scheduled when the module unbinds, could this lead to a
use-after-free when the pending tasklet executes?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913045001.1126563-1-lgs201920130244@gmail.com?part=1