Re: [PATCH v2 2/5] dmaengine: ti: omap-dma: fix notifier leak in remove

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Potential Use-After-Free of notifier_block due to missing RCU synchronization.
--

commit 5e6f29c5f10bea4aff2b71ed41a418296a887ddf
Author: Rosen Penev <rosenp@gmail.com>

dmaengine: ti: omap-dma: fix notifier leak in remove

This commit fixes a notifier leak during driver removal. It ensures the CPU PM
notifier is unregistered if either the needs_busy_check or may_lose_context
flag is set, rather than only checking may_lose_context.

> diff --git a/drivers/dma/ti/omap-dma.c b/drivers/dma/ti/omap-dma.c
> --- a/drivers/dma/ti/omap-dma.c
> +++ b/drivers/dma/ti/omap-dma.c
> @@ -1853,7 +1853,7 @@ static void omap_dma_remove(struct platform_device *pdev)
>  	struct omap_dmadev *od = platform_get_drvdata(pdev);
>  	int irq;
>  
> -	if (od->cfg->may_lose_context)
> +	if (od->cfg->needs_busy_check || od->cfg->may_lose_context)
>  		cpu_pm_unregister_notifier(&od->nb);

[Severity: Critical]
This is a pre-existing issue, but does this unregister path leave the
notifier_block vulnerable to a use-after-free?

In omap_dma_remove(), cpu_pm_unregister_notifier() unlinks the notifier
block from the raw notifier chain but does not wait for an RCU grace period.
Because the od structure is managed by devres (allocated via devm_kzalloc),
it gets freed automatically shortly after omap_dma_remove() returns.

If a concurrent CPU PM transition (like another CPU entering or exiting idle
states) traverses the raw notifier chain using rcu_read_lock(), couldn't the
traversing CPU dereference the freshly freed notifier_block?

Would adding a synchronization mechanism for RCU before the driver is
released prevent this regression?

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