[PATCH] dmaengine: Fix device kref underflow in dma_chan_put()

[PATCH] dmaengine: Fix device kref underflow in dma_chan_put()

[Shivank Garg]

dma_chan_get() takes chan->device->ref only on the slow path:

	/* no kref on fast path */
	if (chan->client_count) {
		__module_get(owner);
		chan->client_count++;
		return 0;
	}
	if (!try_module_get(owner))
		return -ENODEV;
	ret = kref_get_unless_zero(&chan->device->ref);

dma_chan_put() drops the ref unconditionally, so every fast-path
get/put pair drops one extra device reference.

The bug fires when two conditions hold together: a non-private
provider has a persistent client holding chan->client_count > 0
and another client cycles dmaengine_get()/dmaengine_put().
When the kref hits zero, the subsequent dma_find_channel() returns
NULL even though the provider module is still loaded.

Fix this by dropping device->ref only on the last put, matching the
single slow-path get.

Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct")
Signed-off-by: Shivank Garg <shivankg@amd.com>
---
 drivers/dma/dmaengine.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 405bd2fbb4a3b94fd0bf44526f656f6a19feaad0..605bfa477a004cc0b03957ffb85a52308f903441 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);
 	module_put(dma_chan_to_owner(chan));
 }
 

---
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
change-id: 20260518-dmaengine-kref-fix-7b21acb09455

Best regards,
-- 
Shivank Garg <shivankg@amd.com>

Re: [PATCH] dmaengine: Fix device kref underflow in dma_chan_put()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Pre-existing Use-After-Free vulnerabilities in dma_chan_put() and dma_release_channel() due to device memory release before teardown completes.
--

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

dmaengine: Fix device kref underflow in dma_chan_put()

This commit addresses a device kref underflow by ensuring the device reference
is only dropped when the client count reaches zero, matching the slow-path get.

> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> --- 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);
>  	module_put(dma_chan_to_owner(chan));
>  }

This isn't a bug introduced by this patch, but does this sequence present
a use-after-free risk?

If dma_device_put() drops the final reference to the device (for example,
if the provider module previously unregistered the DMA device), it can
trigger the device release callback and free the dma_device and dma_chan
memory.

If that happens, module_put(dma_chan_to_owner(chan)) will dereference the
freed memory, as dma_chan_to_owner() accesses chan->device->owner.

Additionally, when dma_chan_put() is called from dma_release_channel(),
returning from this function leads to further accesses of the freed memory.
dma_release_channel() continues to access chan->device->privatecnt,
chan->device->cap_mask, chan->slave, and chan->name, which could cause a
series of use-after-free issues during teardown or hot-unplug.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518-dmaengine-kref-fix-v1-1-4d6125048fb7@amd.com?part=1

Re: [PATCH] dmaengine: Fix device kref underflow in dma_chan_put()

[Garg, Shivank]

On 5/18/2026 1:59 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Pre-existing Use-After-Free vulnerabilities in dma_chan_put() and dma_release_channel() due to device memory release before teardown completes.
> --
> 
> commit dcce1cbcc027c7a50b03bed56fe875a7390be677
> Author: Shivank Garg <shivankg@amd.com>
> 
> dmaengine: Fix device kref underflow in dma_chan_put()
> 
> This commit addresses a device kref underflow by ensuring the device reference
> is only dropped when the client count reaches zero, matching the slow-path get.
> 
>> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
>> --- 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);
>>       module_put(dma_chan_to_owner(chan));
>>  }
> 
> This isn't a bug introduced by this patch, but does this sequence present
> a use-after-free risk?
> 
> If dma_device_put() drops the final reference to the device (for example,
> if the provider module previously unregistered the DMA device), it can
> trigger the device release callback and free the dma_device and dma_chan
> memory.
> 
> If that happens, module_put(dma_chan_to_owner(chan)) will dereference the
> freed memory, as dma_chan_to_owner() accesses chan->device->owner.
> 
> Additionally, when dma_chan_put() is called from dma_release_channel(),
> returning from this function leads to further accesses of the freed memory.
> dma_release_channel() continues to access chan->device->privatecnt,
> chan->device->cap_mask, chan->slave, and chan->name, which could cause a
> series of use-after-free issues during teardown or hot-unplug.
> 
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260518-dmaengine-kref-fix-v1-1-4d6125048fb7@amd.com?part=1

Thanks, this makes sense.

I'm able to reproduce the dma_chan_put() use-after-free issue with KASAN:

            slab-use-after-free in dma_chan_put+0x3e6/0x4c0
            Read of size 8 by task insmod/6319
            Freed by task 6319:
              kfree+0x225/0x470
              dma_chan_put+0x395/0x4c0
              dmaengine_put+0xf8/0x160

I'll add the fix for this in next posting.

Best regards,
Shivank

Re: [PATCH] dmaengine: Fix device kref underflow in dma_chan_put()

[Garg, Shivank]

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]



On 5/18/2026 1:59 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Pre-existing Use-After-Free vulnerabilities in dma_chan_put() and dma_release_channel() due to device memory release before teardown completes.
> --
> 
> commit dcce1cbcc027c7a50b03bed56fe875a7390be677
> Author: Shivank Garg <shivankg@amd.com>
> 
> dmaengine: Fix device kref underflow in dma_chan_put()
> 
> This commit addresses a device kref underflow by ensuring the device reference
> is only dropped when the client count reaches zero, matching the slow-path get.
> 
>> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
>> --- 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);
>>       module_put(dma_chan_to_owner(chan));
>>  }
> 
> This isn't a bug introduced by this patch, but does this sequence present
> a use-after-free risk?
> 
> If dma_device_put() drops the final reference to the device (for example,
> if the provider module previously unregistered the DMA device), it can
> trigger the device release callback and free the dma_device and dma_chan
> memory.
> 
> If that happens, module_put(dma_chan_to_owner(chan)) will dereference the
> freed memory, as dma_chan_to_owner() accesses chan->device->owner.
> 
> Additionally, when dma_chan_put() is called from dma_release_channel(),
> returning from this function leads to further accesses of the freed memory.
> dma_release_channel() continues to access chan->device->privatecnt,
> chan->device->cap_mask, chan->slave, and chan->name, which could cause a
> series of use-after-free issues during teardown or hot-unplug.
> 
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260518-dmaengine-kref-fix-v1-1-4d6125048fb7@amd.com?part=1

Attached the patch addressing the Sashiko reported issues for additional review
comments before sending out v2.

Thanks,
Shivank

[-- Attachment #2: 0001-dmaengine-fix-use-after-free-in-dma_chan_put-and-dma.patch --]
[-- Type: text/plain, Size: 2981 bytes --]

From c02ce8c61acc4a2f4e2c9f09bd1681c72a98c4a1 Mon Sep 17 00:00:00 2001
From: Shivank Garg <shivankg@amd.com>
Date: Mon, 18 May 2026 11:49:09 +0000
Subject: [PATCH] dmaengine: fix use-after-free in dma_chan_put() and
 dma_release_channel()

When dma_device_put() drops the last reference on chan->device->ref,
dma_device_release() runs and may free the dma_device along with its
channels.

Two paths still read that memory after the put:
 - dma_chan_put() reads chan->device->owner via dma_chan_to_owner()
   for the trailing module_put().
 - dma_release_channel() calls dma_chan_put() first, then reads
   chan->device->privatecnt, chan->slave, chan->name and
   chan->dbg_client_name.

KASAN catches the first one:

	slab-use-after-free in dma_chan_put+0x3e6/0x4c0
	Read of size 8 by task insmod/6319
	Freed by task 6319:
	  kfree+0x225/0x470
	  dma_chan_put+0x395/0x4c0
	  dmaengine_put+0xf8/0x160

Cache the module owner in dma_chan_put() before the put so the trailing
module_put() does not need chan->device. In dma_release_channel(), move
dma_chan_put() to the end, after every chan/device read.

Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct")
Suggested-by: Sashiko <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260518-dmaengine-kref-fix-v1-1-4d6125048fb7@amd.com
Signed-off-by: Shivank Garg <shivankg@amd.com>
---
 drivers/dma/dmaengine.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 605bfa477a00..9c4e206f2468 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -495,10 +495,13 @@ static int dma_chan_get(struct dma_chan *chan)
  */
 static void dma_chan_put(struct dma_chan *chan)
 {
+	struct module *owner;
+
 	/* This channel is not in use, bail out */
 	if (!chan->client_count)
 		return;
 
+	owner = dma_chan_to_owner(chan);
 	chan->client_count--;
 
 	/* This channel is not in use anymore, free it */
@@ -518,7 +521,7 @@ static void dma_chan_put(struct dma_chan *chan)
 	/* This channel is not in use anymore, drop the device ref */
 	if (!chan->client_count)
 		dma_device_put(chan->device);
-	module_put(dma_chan_to_owner(chan));
+	module_put(owner);
 }
 
 enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie)
@@ -907,7 +910,6 @@ void dma_release_channel(struct dma_chan *chan)
 	mutex_lock(&dma_list_mutex);
 	WARN_ONCE(chan->client_count != 1,
 		  "chan reference count %d != 1\n", chan->client_count);
-	dma_chan_put(chan);
 	/* drop PRIVATE cap enabled by __dma_request_channel() */
 	if (--chan->device->privatecnt == 0)
 		dma_cap_clear(DMA_PRIVATE, chan->device->cap_mask);
@@ -924,6 +926,7 @@ void dma_release_channel(struct dma_chan *chan)
 	kfree(chan->dbg_client_name);
 	chan->dbg_client_name = NULL;
 #endif
+	dma_chan_put(chan);
 	mutex_unlock(&dma_list_mutex);
 }
 EXPORT_SYMBOL_GPL(dma_release_channel);

base-commit: 075072b8f04ed897ddc079f0005f15fd5797edf8
-- 
2.43.0