Re: [PATCH v2 1/2] dmaengine: Fix device kref underflow in dma_chan_put()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] RCU Use-After-Free during device release.
- [High] Double `list_del_rcu()` leading to list corruption and kernel crash.
--

commit c36a9f0553b166fe38c0d70bbc4a093494dada44
Author: Shivank Garg <shivankg@amd.com>

dmaengine: Fix device kref underflow in dma_chan_put()

This commit fixes a kref underflow in dma_chan_put() by ensuring that the
device reference is dropped only on the last put, matching the slow-path
get. It prevents situations where a fast-path get/put pair drops an extra
reference, leading to a zero kref and a subsequent dma_find_channel()
returning NULL.

> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 405bd2fbb4a3b..605bfa477a004 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -515,7 +515,9 @@ static void dma_chan_put(struct dma_chan *chan)
>  		chan->route_data = NULL;
>  	}
>  
> -	dma_device_put(chan->device);
> +	/* This channel is not in use anymore, drop the device ref */
> +	if (!chan->client_count)
> +		dma_device_put(chan->device);

[Severity: Critical]
This is a pre-existing issue, but does device release here allow an RCU
use-after-free regression?

In dma_issue_pending_all(), the dma_device_list is iterated using
list_for_each_entry_rcu() under rcu_read_lock().

However, when a device is released, dma_device_release() removes it from
the list with list_del_rcu() and immediately calls device->device_release()
(which in many drivers, such as plx_dma.c, directly calls kfree()).

Because there is no synchronize_rcu() or equivalent mechanism to wait
for the RCU grace period before freeing the memory, concurrent RCU
readers in dma_issue_pending_all() can access freed memory, leading to
a use-after-free.

[Severity: High]
This is a pre-existing issue, but can the module unloading sequence
lead to a double list_del_rcu() regression and list corruption?

In dmaengine_get(), if dma_chan_get(chan) returns -ENODEV (which occurs
when the driver module is unloading and try_module_get() fails), it
explicitly calls list_del_rcu(&device->global_node).

Subsequently, the module's exit routine will call
dma_async_device_unregister(), which eventually calls dma_device_put().

If the reference count drops to zero here, dma_device_release() runs and
unconditionally calls list_del_rcu(&device->global_node) again.

Calling list_del_rcu() on an already unlinked list node manipulates
LIST_POISON pointers, predictably leading to a kernel crash.

>  	module_put(dma_chan_to_owner(chan));
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526-dmaengine-kref-fix-v2-0-3df60afac01d@amd.com?part=1