[BUG] KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

[BUG] KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

[Shuangpeng]

Hi Kernel Maintainers,

I hit the following KASAN report while testing current upstream kernel:

KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)

The reproducer and .config files are here.
https://gist.github.com/shuangpengbai/167620d391d9634107bfe4d784fcf52b

I’m happy to test debug patches or provide additional information.

Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>


[ 2019.816807][T10106] ==================================================================
[ 2019.819081][T10106] BUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406)
[ 2019.820996][T10106] Read of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106
[ 2019.822432][T10106]
[ 2019.822899][T10106] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 2019.822904][T10106] Call Trace:
[ 2019.822910][T10106]  <TASK>
[ 2019.822915][T10106]  dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
[ 2019.822932][T10106]  print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
[ 2019.822984][T10106]  kasan_report (mm/kasan/report.c:595)
[ 2019.823015][T10106]  dev_driver_string (drivers/base/core.c:2406)
[ 2019.823021][T10106]  __dynamic_dev_dbg (lib/dynamic_debug.c:906)
[ 2019.823282][T10106]  chaoskey_release (drivers/usb/misc/chaoskey.c:323)
[ 2019.823290][T10106]  __fput (fs/file_table.c:510)
[ 2019.823298][T10106]  fput_close_sync (fs/file_table.c:615)
[ 2019.823320][T10106]  __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492)
[ 2019.823327][T10106]  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[ 2019.823337][T10106]  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[ 2019.823344][T10106] RIP: 0033:0x7f52411ffc03
[ 2019.823352][T10106] Code: e9 37 ff ff ff e8 2d f9 01 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8
All code
========
   0:	e9 37 ff ff ff       	jmp    0xffffffffffffff3c
   5:	e8 2d f9 01 00       	call   0x1f937
   a:	66 2e 0f 1f 84 00 00 	cs nopw 0x0(%rax,%rax,1)
  11:	00 00 00 
  14:	0f 1f 00             	nopl   (%rax)
  17:	64 8b 04 25 18 00 00 	mov    %fs:0x18,%eax
  1e:	00 
  1f:	85 c0                	test   %eax,%eax
  21:	75 14                	jne    0x37
  23:	b8 03 00 00 00       	mov    $0x3,%eax
  28:	0f 05                	syscall
  2a:*	48 3d 00 f0 ff ff    	cmp    $0xfffffffffffff000,%rax		<-- trapping instruction
  30:	77 45                	ja     0x77
  32:	c3                   	ret
  33:	0f 1f 40 00          	nopl   0x0(%rax)
  37:	48 83 ec 18          	sub    $0x18,%rsp
  3b:	89 7c 24 0c          	mov    %edi,0xc(%rsp)
  3f:	e8                   	.byte 0xe8

Code starting with the faulting instruction
===========================================
   0:	48 3d 00 f0 ff ff    	cmp    $0xfffffffffffff000,%rax
   6:	77 45                	ja     0x4d
   8:	c3                   	ret
   9:	0f 1f 40 00          	nopl   0x0(%rax)
   d:	48 83 ec 18          	sub    $0x18,%rsp
  11:	89 7c 24 0c          	mov    %edi,0xc(%rsp)
  15:	e8                   	.byte 0xe8
[ 2019.823358][T10106] RSP: 002b:00007ffd4b423688 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
[ 2019.823382][T10106] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f52411ffc03
[ 2019.823388][T10106] RDX: 0000000000000000 RSI: 00007ffd4b421570 RDI: 0000000000000003
[ 2019.823400][T10106] RBP: 00007ffd4b423af0 R08: 00007f52412a3040 R09: 00007f52412a30c0
[ 2019.823404][T10106] R10: fffffffffffff639 R11: 0000000000000246 R12: 00007ffd4b4238f0
[ 2019.823408][T10106] R13: 0000000000000003 R14: 0000000000000000 R15: 000000000000277c
[ 2019.823417][T10106]  </TASK>
[ 2019.823420][T10106]
[ 2019.842033][T10106] Freed by task 10106 on cpu 0 at 2019.816700s:
[ 2019.842461][T10106]  kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78)
[ 2019.842793][T10106]  kasan_save_free_info (mm/kasan/generic.c:584)
[ 2019.843137][T10106]  __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)
[ 2019.843463][T10106]  kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)
[ 2019.843736][T10106]  device_release (drivers/base/core.c:2562)
[ 2019.844053][T10106]  kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737)
[ 2019.844368][T10106]  chaoskey_free (drivers/usb/misc/chaoskey.c:103)
[ 2019.844696][T10106]  chaoskey_release (drivers/usb/misc/chaoskey.c:315)
[ 2019.845038][T10106]  __fput (fs/file_table.c:510)
[ 2019.845322][T10106]  fput_close_sync (fs/file_table.c:615)
[ 2019.845651][T10106]  __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492)
[ 2019.845981][T10106]  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[ 2019.846302][T10106]  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[ 2019.846708][T10106]
[ 2019.846874][T10106] The buggy address belongs to the object at ffff888168e8a000
[ 2019.846874][T10106]  which belongs to the cache kmalloc-1k of size 1024
[ 2019.847827][T10106] The buggy address is located 184 bytes inside of
[ 2019.847827][T10106]  freed 1024-byte region [ffff888168e8a000, ffff888168e8a400)


Best,
Shuangpeng

Re: [BUG] KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

[Alan Stern]

On Sat, Jun 06, 2026 at 09:31:30PM -0400, Shuangpeng wrote:
> Hi Kernel Maintainers,
> 
> I hit the following KASAN report while testing current upstream kernel:
> 
> KASAN: slab-use-after-free in dev_driver_string from chaoskey_release
> 
> on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
> 
> The reproducer and .config files are here.
> https://gist.github.com/shuangpengbai/167620d391d9634107bfe4d784fcf52b
> 
> I’m happy to test debug patches or provide additional information.
> 
> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
> 
> 
> [ 2019.816807][T10106] ==================================================================
> [ 2019.819081][T10106] BUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406)
> [ 2019.820996][T10106] Read of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106
> [ 2019.822432][T10106]
> [ 2019.822899][T10106] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> [ 2019.822904][T10106] Call Trace:
> [ 2019.822910][T10106]  <TASK>
> [ 2019.822915][T10106]  dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
> [ 2019.822932][T10106]  print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
> [ 2019.822984][T10106]  kasan_report (mm/kasan/report.c:595)
> [ 2019.823015][T10106]  dev_driver_string (drivers/base/core.c:2406)
> [ 2019.823021][T10106]  __dynamic_dev_dbg (lib/dynamic_debug.c:906)
> [ 2019.823282][T10106]  chaoskey_release (drivers/usb/misc/chaoskey.c:323)

The simple explanation is that the chaoskey_release() routine contains 
debugging statements that reference an interface for the USB device even 
after that data structure may have been deallocated.  Since they are 
merely debugging statements, the simplest solution to the problem is to 
get rid of them.

That's what the patch below does.  You can try it out and see if it 
works.

Alan Stern



Index: usb-devel/drivers/usb/misc/chaoskey.c
===================================================================
--- usb-devel.orig/drivers/usb/misc/chaoskey.c
+++ usb-devel/drivers/usb/misc/chaoskey.c
@@ -294,15 +294,10 @@ static int chaoskey_release(struct inode
 
 	interface = dev->interface;
 
-	usb_dbg(interface, "release");
-
 	mutex_lock(&chaoskey_list_lock);
 	mutex_lock(&dev->lock);
 
-	usb_dbg(interface, "open count at release is %d", dev->open);
-
 	if (dev->open <= 0) {
-		usb_dbg(interface, "invalid open count (%d)", dev->open);
 		rv = -ENODEV;
 		goto bail;
 	}
@@ -320,7 +315,6 @@ bail:
 	mutex_unlock(&dev->lock);
 destruction:
 	mutex_unlock(&chaoskey_list_lock);
-	usb_dbg(interface, "release success");
 	return rv;
 }
 

Re: [BUG] KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

[Shuangpeng]

> On Jun 6, 2026, at 22:29, Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> On Sat, Jun 06, 2026 at 09:31:30PM -0400, Shuangpeng wrote:
>> Hi Kernel Maintainers,
>> 
>> I hit the following KASAN report while testing current upstream kernel:
>> 
>> KASAN: slab-use-after-free in dev_driver_string from chaoskey_release
>> 
>> on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
>> 
>> The reproducer and .config files are here.
>> https://gist.github.com/shuangpengbai/167620d391d9634107bfe4d784fcf52b
>> 
>> I’m happy to test debug patches or provide additional information.
>> 
>> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
>> 
>> 
>> [ 2019.816807][T10106] ==================================================================
>> [ 2019.819081][T10106] BUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406)
>> [ 2019.820996][T10106] Read of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106
>> [ 2019.822432][T10106]
>> [ 2019.822899][T10106] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
>> [ 2019.822904][T10106] Call Trace:
>> [ 2019.822910][T10106]  <TASK>
>> [ 2019.822915][T10106]  dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
>> [ 2019.822932][T10106]  print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
>> [ 2019.822984][T10106]  kasan_report (mm/kasan/report.c:595)
>> [ 2019.823015][T10106]  dev_driver_string (drivers/base/core.c:2406)
>> [ 2019.823021][T10106]  __dynamic_dev_dbg (lib/dynamic_debug.c:906)
>> [ 2019.823282][T10106]  chaoskey_release (drivers/usb/misc/chaoskey.c:323)
> 
> The simple explanation is that the chaoskey_release() routine contains 
> debugging statements that reference an interface for the USB device even 
> after that data structure may have been deallocated.  Since they are 
> merely debugging statements, the simplest solution to the problem is to 
> get rid of them.
> 
> That's what the patch below does.  You can try it out and see if it 
> works.

I tried this patch and the bug is no longer triggered on my side.

Thanks for your fix!

> 
> Alan Stern
> 
> 
> 
> Index: usb-devel/drivers/usb/misc/chaoskey.c
> ===================================================================
> --- usb-devel.orig/drivers/usb/misc/chaoskey.c
> +++ usb-devel/drivers/usb/misc/chaoskey.c
> @@ -294,15 +294,10 @@ static int chaoskey_release(struct inode
> 
> interface = dev->interface;
> 
> - usb_dbg(interface, "release");
> -
> mutex_lock(&chaoskey_list_lock);
> mutex_lock(&dev->lock);
> 
> - usb_dbg(interface, "open count at release is %d", dev->open);
> -
> if (dev->open <= 0) {
> - usb_dbg(interface, "invalid open count (%d)", dev->open);
> rv = -ENODEV;
> goto bail;
> }
> @@ -320,7 +315,6 @@ bail:
> mutex_unlock(&dev->lock);
> destruction:
> mutex_unlock(&chaoskey_list_lock);
> - usb_dbg(interface, "release success");
> return rv;
> }

Re: [BUG] KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

[Oliver Neukum]

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

On 07.06.26 04:29, Alan Stern wrote:
  
> The simple explanation is that the chaoskey_release() routine contains
> debugging statements that reference an interface for the USB device even
> after that data structure may have been deallocated.  Since they are
> merely debugging statements, the simplest solution to the problem is to
> get rid of them.
> 
> That's what the patch below does.  You can try it out and see if it
> works.

Hi,

correct but it misses the same issue in disconnect.
You need this one on top.

	Regards
		Oliver

[-- Attachment #2: 0001-usb-misc-chaoskey-fix-UAF-in-disconnect.patch --]
[-- Type: text/x-patch, Size: 1266 bytes --]

From 5864a7f4580707a39e3f5881ce31289095984dff Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Mon, 8 Jun 2026 13:20:35 +0200
Subject: [PATCH] usb: misc: chaoskey: fix UAF in disconnect

disconnect has the same issue as release.
The debug output refers to a potentially freed device.
Just remove it.

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/usb/misc/chaoskey.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/usb/misc/chaoskey.c b/drivers/usb/misc/chaoskey.c
index bf4d9294c7c9..0df337089618 100644
--- a/drivers/usb/misc/chaoskey.c
+++ b/drivers/usb/misc/chaoskey.c
@@ -222,12 +222,9 @@ static void chaoskey_disconnect(struct usb_interface *interface)
 {
 	struct chaoskey	*dev;
 
-	usb_dbg(interface, "disconnect");
 	dev = usb_get_intfdata(interface);
-	if (!dev) {
-		usb_dbg(interface, "disconnect failed - no dev");
+	if (!dev)
 		return;
-	}
 
 	if (dev->hwrng_registered)
 		hwrng_unregister(&dev->hwrng);
@@ -248,7 +245,6 @@ static void chaoskey_disconnect(struct usb_interface *interface)
 		mutex_unlock(&dev->lock);
 
 	mutex_unlock(&chaoskey_list_lock);
-	usb_dbg(interface, "disconnect done");
 }
 
 static int chaoskey_open(struct inode *inode, struct file *file)
-- 
2.54.0

Re: [BUG] KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

[Alan Stern]

On Mon, Jun 08, 2026 at 01:24:03PM +0200, Oliver Neukum wrote:
> On 07.06.26 04:29, Alan Stern wrote:
> > The simple explanation is that the chaoskey_release() routine contains
> > debugging statements that reference an interface for the USB device even
> > after that data structure may have been deallocated.  Since they are
> > merely debugging statements, the simplest solution to the problem is to
> > get rid of them.
> > 
> > That's what the patch below does.  You can try it out and see if it
> > works.
> 
> Hi,
> 
> correct but it misses the same issue in disconnect.
> You need this one on top.

You're partly right.  Both my original patch and yours ignored the fact 
that the driver takes a reference to the interface structure.  That 
reference isn't dropped until chaoskey_free() runs, so the only 
debugging statements that need to be removed are the ones following 
calls to chaoskey_free().

Shuangpeng, can you test this patch instead of the earlier one?

Alan Stern


Index: usb-devel/drivers/usb/misc/chaoskey.c
===================================================================
--- usb-devel.orig/drivers/usb/misc/chaoskey.c
+++ usb-devel/drivers/usb/misc/chaoskey.c
@@ -248,7 +248,6 @@ static void chaoskey_disconnect(struct u
 		mutex_unlock(&dev->lock);
 
 	mutex_unlock(&chaoskey_list_lock);
-	usb_dbg(interface, "disconnect done");
 }
 
 static int chaoskey_open(struct inode *inode, struct file *file)
@@ -320,7 +319,6 @@ bail:
 	mutex_unlock(&dev->lock);
 destruction:
 	mutex_unlock(&chaoskey_list_lock);
-	usb_dbg(interface, "release success");
 	return rv;
 }
 

Re: [BUG] KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

[Johan Hovold]

On Mon, Jun 08, 2026 at 09:29:23AM -0400, Alan Stern wrote:

> You're partly right.  Both my original patch and yours ignored the fact 
> that the driver takes a reference to the interface structure.  That 
> reference isn't dropped until chaoskey_free() runs, so the only 
> debugging statements that need to be removed are the ones following 
> calls to chaoskey_free().

> Index: usb-devel/drivers/usb/misc/chaoskey.c
> ===================================================================
> --- usb-devel.orig/drivers/usb/misc/chaoskey.c
> +++ usb-devel/drivers/usb/misc/chaoskey.c
> @@ -248,7 +248,6 @@ static void chaoskey_disconnect(struct u
>  		mutex_unlock(&dev->lock);
>  
>  	mutex_unlock(&chaoskey_list_lock);
> -	usb_dbg(interface, "disconnect done");

There is no need to remove this one as driver core holds a reference to
the interface until after disconnect() returns.

>  }
>  
>  static int chaoskey_open(struct inode *inode, struct file *file)
> @@ -320,7 +319,6 @@ bail:
>  	mutex_unlock(&dev->lock);
>  destruction:
>  	mutex_unlock(&chaoskey_list_lock);
> -	usb_dbg(interface, "release success");
>  	return rv;
>  }

Johan

Re: [BUG] KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

[Alan Stern]

On Mon, Jun 08, 2026 at 05:11:27PM +0200, Johan Hovold wrote:
> On Mon, Jun 08, 2026 at 09:29:23AM -0400, Alan Stern wrote:
> 
> > You're partly right.  Both my original patch and yours ignored the fact 
> > that the driver takes a reference to the interface structure.  That 
> > reference isn't dropped until chaoskey_free() runs, so the only 
> > debugging statements that need to be removed are the ones following 
> > calls to chaoskey_free().
> 
> > Index: usb-devel/drivers/usb/misc/chaoskey.c
> > ===================================================================
> > --- usb-devel.orig/drivers/usb/misc/chaoskey.c
> > +++ usb-devel/drivers/usb/misc/chaoskey.c
> > @@ -248,7 +248,6 @@ static void chaoskey_disconnect(struct u
> >  		mutex_unlock(&dev->lock);
> >  
> >  	mutex_unlock(&chaoskey_list_lock);
> > -	usb_dbg(interface, "disconnect done");
> 
> There is no need to remove this one as driver core holds a reference to
> the interface until after disconnect() returns.

Yes, you're right of course.  And I'm annoyed, because I had realized 
exactly the same thing before noticing the usb_get_intf() and 
usb_put_intf() calls, and then forgot about it when updating the patch!

The final version of the patch is below.

Alan Stern


Index: usb-devel/drivers/usb/misc/chaoskey.c
===================================================================
--- usb-devel.orig/drivers/usb/misc/chaoskey.c
+++ usb-devel/drivers/usb/misc/chaoskey.c
@@ -320,7 +320,6 @@ bail:
 	mutex_unlock(&dev->lock);
 destruction:
 	mutex_unlock(&chaoskey_list_lock);
-	usb_dbg(interface, "release success");
 	return rv;
 }
 

Re: [BUG] KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

[Shuangpeng]

> On Jun 8, 2026, at 12:03, Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> On Mon, Jun 08, 2026 at 05:11:27PM +0200, Johan Hovold wrote:
>> On Mon, Jun 08, 2026 at 09:29:23AM -0400, Alan Stern wrote:
>> 
>>> You're partly right.  Both my original patch and yours ignored the fact 
>>> that the driver takes a reference to the interface structure.  That 
>>> reference isn't dropped until chaoskey_free() runs, so the only 
>>> debugging statements that need to be removed are the ones following 
>>> calls to chaoskey_free().
>> 
>>> Index: usb-devel/drivers/usb/misc/chaoskey.c
>>> ===================================================================
>>> --- usb-devel.orig/drivers/usb/misc/chaoskey.c
>>> +++ usb-devel/drivers/usb/misc/chaoskey.c
>>> @@ -248,7 +248,6 @@ static void chaoskey_disconnect(struct u
>>> mutex_unlock(&dev->lock);
>>> 
>>> mutex_unlock(&chaoskey_list_lock);
>>> - usb_dbg(interface, "disconnect done");
>> 
>> There is no need to remove this one as driver core holds a reference to
>> the interface until after disconnect() returns.
> 
> Yes, you're right of course.  And I'm annoyed, because I had realized 
> exactly the same thing before noticing the usb_get_intf() and 
> usb_put_intf() calls, and then forgot about it when updating the patch!
> 
> The final version of the patch is below.
> 
> Alan Stern
> 

I tested this patch. It works on my side. Thank you!

> 
> Index: usb-devel/drivers/usb/misc/chaoskey.c
> ===================================================================
> --- usb-devel.orig/drivers/usb/misc/chaoskey.c
> +++ usb-devel/drivers/usb/misc/chaoskey.c
> @@ -320,7 +320,6 @@ bail:
> mutex_unlock(&dev->lock);
> destruction:
> mutex_unlock(&chaoskey_list_lock);
> - usb_dbg(interface, "release success");
> return rv;
> }

Re: [BUG] KASAN: slab-use-after-free in dev_driver_string from chaoskey_release

[Johan Hovold]

On Mon, Jun 08, 2026 at 01:24:03PM +0200, Oliver Neukum wrote:
> On 07.06.26 04:29, Alan Stern wrote:
>   
> > The simple explanation is that the chaoskey_release() routine contains
> > debugging statements that reference an interface for the USB device even
> > after that data structure may have been deallocated.  Since they are
> > merely debugging statements, the simplest solution to the problem is to
> > get rid of them.
> > 
> > That's what the patch below does.  You can try it out and see if it
> > works.

> correct but it misses the same issue in disconnect.
> You need this one on top.

No, it's perfectly fine to access the interface in the disconnect
callback.

It's only after disconnect() returns that you need an extra reference.

Johan