WARNING in cm109_urb_irq_callback/usb_submit_urb

WARNING in cm109_urb_irq_callback/usb_submit_urb

[白烁冉]

Dear Maintainers,

When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.


HEAD commit: 6537cfb395f352782918d8ee7b7f10ba2cc3cbf2
git tree: upstream
Output:https://github.com/pghk13/Kernel-Bug/tree/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open
Kernel config:https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/config.txt
C reproducer:https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open/94repro.c
Syzlang reproducer: https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open/94report


The error occurs around line 379 of the urb.c file. The problem ends up in the cm109_urb_irq_callback function in the cm109.c file:In the cm109_urb_irq_callback function, the driver attempts to resubmit a URB that has not yet been processed. There may be a race condition in the driver that resubmits the URB in the URB completion callback, but the same URB may have already been committed to another location in the system. This issue seems to involve the creation of USB devices, the operation of TTY devices, and file descriptor copying. This complex interaction resulted in duplicate commits of the URB.
We have reproduced this issue several times on 6.14-rc5 again.




If you fix this issue, please add the following tag to the commit:
Reported-by: Kun Hu <huk23@m.fudan.edu.cn>, Jiaji Qin <jjtan24@m.fudan.edu.cn>, Shuoran Bai <baishuoran@hrbeu.edu.cn>


================================================================== 
URB ffff888045c81800 submitted while active
WARNING: CPU: 0 PID: 0 at drivers/usb/core/urb.c:379 usb_submit_urb+0x134e/0x1750
Modules linked in:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.14.0-rc5 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:usb_submit_urb+0x134e/0x1750
Code: e8 c7 b4 a0 fa 84 db 0f 85 47 f5 ff ff e8 0a b3 a0 fa c6 05 c3 ba 30 09 01 90 48 c7 c7 00 3e 2f 8c 4c 89 fe e8 e3 a8 60 fa 90 <0f> 0b 90 90 e9 21 f5 ff ff 48 89 7c 24 38 e8 df b2 a0 fa 48 8b 7c
RSP: 0018:ffffc90000007ad0 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8179ec7a
RDX: 0000000000000000 RSI: ffffffff8de97740 RDI: 0000000000000002
RBP: ffff888022bee740 R08: 0000000000000000 R09: ffffed1005705182
R10: ffffed1005705181 R11: ffff88802b828c0b R12: 0000000000000046
R13: ffff888027b24058 R14: 00000000fffffff0 R15: ffff888045c81800
FS:  0000000000000000(0000) GS:ffff88802b800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fffca04ff60 CR3: 000000000df80000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 <IRQ>
 cm109_urb_irq_callback+0x44b/0xb60
 __usb_hcd_giveback_urb+0x2e4/0x6b0
 usb_hcd_giveback_urb+0x391/0x450
 dummy_timer+0x1217/0x3540
 __hrtimer_run_queues+0x1b7/0xc30
 hrtimer_run_softirq+0x17f/0x2e0
 handle_softirqs+0x1bd/0x880
 irq_exit_rcu+0xfd/0x150
 sysvec_apic_timer_interrupt+0xa8/0xc0
 </IRQ>
 <TASK>
 asm_sysvec_apic_timer_interrupt+0x1a/0x20
RIP: 0010:default_idle+0x1e/0x30
Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 eb 0c 0f 1f 44 00 00 0f 00 2d c9 a9 0d 00 0f 1f 44 00 00 fb f4 <fa> e9 a7 41 b7 f5 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90
RSP: 0018:ffffffff8de07e08 EFLAGS: 00000206
RAX: 000000000027dec5 RBX: 0000000000000000 RCX: ffffffff8b58e5a7
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: dffffc0000000000 R08: 0000000000000001 R09: ffffed1005706f86
R10: ffffed1005706f85 R11: ffff88802b837c2b R12: 0000000000000000
R13: ffffffff90616a10 R14: 0000000000000000 R15: 0000000000000000
 default_idle_call+0x6d/0xb0
 do_idle+0x312/0x3c0
 cpu_startup_entry+0x4f/0x60
 rest_init+0x1a9/0x2f0
 start_kernel+0x3fa/0x4e0
 x86_64_start_reservations+0x18/0x30
 x86_64_start_kernel+0xb3/0xc0
 common_startup_64+0x13e/0x148
 </TASK>
--------------------------------
Code disassembly (best guess):
   0:	90                   	nop
   1:	90                   	nop
   2:	90                   	nop
   3:	90                   	nop
   4:	90                   	nop
   5:	90                   	nop
   6:	90                   	nop
   7:	90                   	nop
   8:	90                   	nop
   9:	90                   	nop
   a:	90                   	nop
   b:	90                   	nop
   c:	f3 0f 1e fa          	endbr64
  10:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)
  15:	eb 0c                	jmp    0x23
  17:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)
  1c:	0f 00 2d c9 a9 0d 00 	verw   0xda9c9(%rip)        # 0xda9ec
  23:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)
  28:	fb                   	sti
  29:	f4                   	hlt
* 2a:	fa                   	cli <-- trapping instruction
  2b:	e9 a7 41 b7 f5       	jmpq   0xf5b741d7
  30:	66 66 2e 0f 1f 84 00 	data16 nopw %cs:0x0(%rax,%rax,1)
  37:	00 00 00 00
  3b:	90                   	nop
  3c:	90                   	nop
  3d:	90                   	nop
  3e:	90                   	nop
  3f:	90                   	nop
--------------------------------





thanks,
Kun Hu

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Oliver Neukum]

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



On 20.03.25 05:39, 白烁冉 wrote:
> Dear Maintainers,
> 
> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.
> 

Hi,

is there a way to use the syzkaller for testing a patch?

	Regards
		Oliver

[-- Attachment #2: 0001-USB-cm109-fix-race-between-restarting-and-close.patch --]
[-- Type: text/x-patch, Size: 908 bytes --]

From 03d78ca8c47c8c888df7c7ae2c7109825799d236 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Thu, 20 Mar 2025 14:29:17 +0100
Subject: [PATCH] USB: cm109: fix race between restarting and close

cm109_input_close() can race with cm109_restore_state()
Hence cm109_submit_buzz_toggle() needs to check
the shutdown flag

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/input/misc/cm109.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
index 0cfe5d4a573c..8ae62b5e45f6 100644
--- a/drivers/input/misc/cm109.c
+++ b/drivers/input/misc/cm109.c
@@ -348,6 +348,8 @@ static void cm109_submit_buzz_toggle(struct cm109_dev *dev)
 	else
 		dev->ctl_data->byte[HID_OR0] &= ~BUZZER_ON;
 
+	if (dev->shutdown)
+		return;
 	error = usb_submit_urb(dev->urb_ctl, GFP_ATOMIC);
 	if (error)
 		dev_err(&dev->intf->dev,
-- 
2.48.1

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[胡焜]

> 2025年3月20日 21:35，Oliver Neukum <oneukum@suse.com> 写道：
> 
> 
> On 20.03.25 05:39, 白烁冉 wrote:
>> Dear Maintainers,
>> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.
> 
> Hi,
> 
> is there a way to use the syzkaller for testing a patch?
> 
> Regards
> Oliver
> <0001-USB-cm109-fix-race-between-restarting-and-close.patch>


Thanks,

I’ll test the patch for multiple rounds to check if it works.

Best,
Kun

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Alan Stern]

On Thu, Mar 20, 2025 at 02:35:23PM +0100, Oliver Neukum wrote:
> 
> 
> On 20.03.25 05:39, 白烁冉 wrote:
> > Dear Maintainers,
> > 
> > When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.
> > 
> 
> Hi,
> 
> is there a way to use the syzkaller for testing a patch?
> 
> 	Regards
> 		Oliver

> From 03d78ca8c47c8c888df7c7ae2c7109825799d236 Mon Sep 17 00:00:00 2001
> From: Oliver Neukum <oneukum@suse.com>
> Date: Thu, 20 Mar 2025 14:29:17 +0100
> Subject: [PATCH] USB: cm109: fix race between restarting and close
> 
> cm109_input_close() can race with cm109_restore_state()
> Hence cm109_submit_buzz_toggle() needs to check
> the shutdown flag
> 
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
> ---
>  drivers/input/misc/cm109.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
> index 0cfe5d4a573c..8ae62b5e45f6 100644
> --- a/drivers/input/misc/cm109.c
> +++ b/drivers/input/misc/cm109.c
> @@ -348,6 +348,8 @@ static void cm109_submit_buzz_toggle(struct cm109_dev *dev)
>  	else
>  		dev->ctl_data->byte[HID_OR0] &= ~BUZZER_ON;
>  
> +	if (dev->shutdown)
> +		return;

This test must itself be subject to the same race, right?  There needs 
to be some kind of synchronization between the two tasks (i.e., a mutex, 
spinlock, or something similar).

Alan Stern

>  	error = usb_submit_urb(dev->urb_ctl, GFP_ATOMIC);
>  	if (error)
>  		dev_err(&dev->intf->dev,
> -- 
> 2.48.1

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Oliver Neukum]

On 20.03.25 15:25, Alan Stern wrote:

> This test must itself be subject to the same race, right?  There needs
> to be some kind of synchronization between the two tasks (i.e., a mutex,
> spinlock, or something similar).

Hi,

there is:

static void cm109_stop_traffic(struct cm109_dev *dev)
{
         dev->shutdown = 1;
         /*
          * Make sure other CPUs see this
          */
         smp_wmb();
                 
         usb_kill_urb(dev->urb_ctl);
         usb_kill_urb(dev->urb_irq);
                 
         cm109_toggle_buzzer_sync(dev, 0);
                 
         dev->shutdown = 0;
         smp_wmb();
}

This driver has a tough job as the two completion
handlers submitted each other's as well as their own
URBs based on the data they get.
That scheme is rather complex, but as far as I can tell correct,
but you need to test that flag everywhere.

	Regards
		Oliver
           

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Alan Stern]

On Thu, Mar 20, 2025 at 04:42:33PM +0100, Oliver Neukum wrote:
> On 20.03.25 15:25, Alan Stern wrote:
> 
> > This test must itself be subject to the same race, right?  There needs
> > to be some kind of synchronization between the two tasks (i.e., a mutex,
> > spinlock, or something similar).
> 
> Hi,
> 
> there is:
> 
> static void cm109_stop_traffic(struct cm109_dev *dev)
> {
>         dev->shutdown = 1;
>         /*
>          * Make sure other CPUs see this
>          */
>         smp_wmb();
>         usb_kill_urb(dev->urb_ctl);
>         usb_kill_urb(dev->urb_irq);
>         cm109_toggle_buzzer_sync(dev, 0);
>         dev->shutdown = 0;
>         smp_wmb();

I don't know anything about this driver, but the placement of the second 
smp_wmb() looks odd.  Should it really come before the line that sets 
dev->shutdown to 0?  In general, smp_wmb() is used to separate two sets 
of stores; if it comes after all the relevant stores have been performed 
then it won't accomplish anything.

> }
> 
> This driver has a tough job as the two completion
> handlers submitted each other's as well as their own
> URBs based on the data they get.
> That scheme is rather complex, but as far as I can tell correct,
> but you need to test that flag everywhere.

However, it's quite noticeable that the code you want to change in 
cm109_submit_buzz_toggle() doesn't have any memory barriers to pair with 
the smb_wmb()'s above.  Shouldn't there at least be an smp_rmb() after 
you read dev->shutdown?

As long you're updating the synchronization, it might be a good idea to 
also improve the comment describing the memory barriers.  "Make sure 
other CPUs see this" doesn't mean anything -- of course all the other 
CPUs will eventually see the changes made here.  The point is that they 
should see the new value of dev->shutdown before seeing the final 
completion of the two URBs.  Also, the comment should say which other 
memory barriers pair with the ones here.

Alan Stern

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Oliver Neukum]

Hi,

On 20.03.25 18:25, Alan Stern wrote:

>> static void cm109_stop_traffic(struct cm109_dev *dev)
>> {
>>          dev->shutdown = 1;
>>          /*
>>           * Make sure other CPUs see this
>>           */
>>          smp_wmb();
>>          usb_kill_urb(dev->urb_ctl);
>>          usb_kill_urb(dev->urb_irq);
>>          cm109_toggle_buzzer_sync(dev, 0);
>>          dev->shutdown = 0;
>>          smp_wmb();
> 
> I don't know anything about this driver, but the placement of the second
> smp_wmb() looks odd.  Should it really come before the line that sets

Indeed. This driver is not written for comprehension. As far as I can tell
it is not necessary at all. You need to set shutdown to zero before you
resubmit the URBs. But I don't see how the barrier helps with that.

> dev->shutdown to 0?  In general, smp_wmb() is used to separate two sets
> of stores; if it comes after all the relevant stores have been performed
> then it won't accomplish anything.

Don't we guarantee an interaction between smp_wmb() and taking a spinlock?
> 
>> }
>>
>> This driver has a tough job as the two completion
>> handlers submitted each other's as well as their own
>> URBs based on the data they get.
>> That scheme is rather complex, but as far as I can tell correct,
>> but you need to test that flag everywhere.
> 
> However, it's quite noticeable that the code you want to change in
> cm109_submit_buzz_toggle() doesn't have any memory barriers to pair with
> the smb_wmb()'s above.  Shouldn't there at least be an smp_rmb() after
> you read dev->shutdown?

I think this driver assumes that the ctl_submit_lock spinlock makes
it safe.

> As long you're updating the synchronization, it might be a good idea to
> also improve the comment describing the memory barriers.  "Make sure
> other CPUs see this" doesn't mean anything -- of course all the other
> CPUs will eventually see the changes made here.  The point is that they
> should see the new value of dev->shutdown before seeing the final
> completion of the two URBs.  Also, the comment should say which other
> memory barriers pair with the ones here.

Before the completion? AFAICT they need to see it before they try
to submit an URB.

	Regards
		Oliver

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Alan Stern]

On Thu, Mar 27, 2025 at 12:42:41PM +0100, Oliver Neukum wrote:
> Hi,
> 
> On 20.03.25 18:25, Alan Stern wrote:
> 
> > > static void cm109_stop_traffic(struct cm109_dev *dev)
> > > {
> > >          dev->shutdown = 1;
> > >          /*
> > >           * Make sure other CPUs see this
> > >           */
> > >          smp_wmb();
> > >          usb_kill_urb(dev->urb_ctl);
> > >          usb_kill_urb(dev->urb_irq);
> > >          cm109_toggle_buzzer_sync(dev, 0);
> > >          dev->shutdown = 0;
> > >          smp_wmb();
> > 
> > I don't know anything about this driver, but the placement of the second
> > smp_wmb() looks odd.  Should it really come before the line that sets
> 
> Indeed. This driver is not written for comprehension. As far as I can tell
> it is not necessary at all. You need to set shutdown to zero before you
> resubmit the URBs. But I don't see how the barrier helps with that.
> 
> > dev->shutdown to 0?  In general, smp_wmb() is used to separate two sets
> > of stores; if it comes after all the relevant stores have been performed
> > then it won't accomplish anything.
> 
> Don't we guarantee an interaction between smp_wmb() and taking a spinlock?

There's no special interaction between them.  Just the usual ordering 
requirement between the smp_wmb() memory barrier and the write part of 
a spin_lock() or spin_unlock().

> > > }
> > > 
> > > This driver has a tough job as the two completion
> > > handlers submitted each other's as well as their own
> > > URBs based on the data they get.
> > > That scheme is rather complex, but as far as I can tell correct,
> > > but you need to test that flag everywhere.
> > 
> > However, it's quite noticeable that the code you want to change in
> > cm109_submit_buzz_toggle() doesn't have any memory barriers to pair with
> > the smb_wmb()'s above.  Shouldn't there at least be an smp_rmb() after
> > you read dev->shutdown?
> 
> I think this driver assumes that the ctl_submit_lock spinlock makes
> it safe.

I haven't looked at the code, but it sounds like a quick audit might be 
in order.

> > As long you're updating the synchronization, it might be a good idea to
> > also improve the comment describing the memory barriers.  "Make sure
> > other CPUs see this" doesn't mean anything -- of course all the other
> > CPUs will eventually see the changes made here.  The point is that they
> > should see the new value of dev->shutdown before seeing the final
> > completion of the two URBs.  Also, the comment should say which other
> > memory barriers pair with the ones here.
> 
> Before the completion? AFAICT they need to see it before they try
> to submit an URB.

My point was that the memory barrier doesn't "make sure other CPUs will 
see this", as the command says.  Rather, it provides ordering: It 
ensures that other CPUs will see the writes preceding the memory barrier 
before they see the writes following the memory barrier.

Hence the comment should be updated, so that it provides information 
that actually is important for someone reading the code to know.

Alan Stern

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[胡焜]

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



> 2025年3月20日 21:35，Oliver Neukum <oneukum@suse.com> 写道：
> 
> 
> On 20.03.25 05:39, 白烁冉 wrote:
>> Dear Maintainers,
>> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.
> 
> Hi,
> 
> is there a way to use the syzkaller for testing a patch?
> 
> Regards
> Oliver
> <0001-USB-cm109-fix-race-between-restarting-and-close.patch>


Hi Oliver,

Sorry for late, our servers have been down for a few days and we just managed to fix it today.

We retested the patch you provided, but we found that the issue still exists, but may be somewhat different from the call trace from the previous issue. I have provided a screenshot in diff form and the full call trace log in the attachment.


——————
Thanks,
Kun Hu


[-- Attachment #2: call trace.txt --]
[-- Type: text/plain, Size: 17832 bytes --]

[  205.291977][    C1] cm109 2-1:0.8: cm109_urb_irq_callback: urb status -71
[  205.294340][    C1] ------------[ cut here ]------------
[  205.294371][    C1] URB ffff888046212a00 submitted while active
[  205.298576][   T31] usb 2-1: USB disconnect, device number 2
[  205.296207][    C1] WARNING: CPU: 1 PID: 13 at drivers/usb/core/urb.c:379 usb_submit_urb+0x134e/0x1750
[  205.296207][    C1] Modules linked in:
[  205.296207][    C1] CPU: 1 UID: 0 PID: 13 Comm: kworker/u16:1 Not tainted 6.14.0 #2
[  205.296207][    C1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[  205.296207][    C1] Workqueue: ipv6_addrconf addrconf_dad_work
[  205.296207][    C1] RIP: 0010:usb_submit_urb+0x134e/0x1750
[  205.296207][    C1] Code: e8 07 19 a0 fa 84 db 0f 85 47 f5 ff ff e8 4a 17 a0 fa c6 05 cd 05 30 09 01 90 48 c7 c7 00 4f 2f 8c 4c 89 fe e8 43 11 60 fa 90 <0f> 0b 90 90 e9 21 f5 ff ff 48 89 7c 24 38 e8 1f 17 a0 fa 48 8b 7c
[  205.296207][    C1] RSP: 0018:ffffc900001f8ae0 EFLAGS: 00010082
[  205.296207][    C1] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817a1c9a
[  205.296207][    C1] RDX: 0000000000000000 RSI: ffff88801d2a8000 RDI: 0000000000000002
[  205.296207][    C1] RBP: ffff8880664cdb20 R08: 0000000000000000 R09: ffffed100fdc5182
[  205.296207][    C1] R10: ffffed100fdc5181 R11: ffff88807ee28c0b R12: 0000000000000046
[  205.296207][    C1] R13: ffff888055310858 R14: 00000000fffffff0 R15: ffff888046212a00
[  205.296207][    C1] FS:  0000000000000000(0000) GS:ffff88807ee00000(0000) knlGS:0000000000000000
[  205.329719][    C1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  205.329719][    C1] CR2: 00007f4d8afa7bac CR3: 000000004c5aa000 CR4: 0000000000750ef0
[  205.329719][    C1] PKRU: 55555554
[  205.329719][    C1] Call Trace:
[  205.329719][    C1]  <IRQ>
[  205.329719][    C1]  ? __warn+0xea/0x3d0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  ? report_bug+0x367/0x5c0
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  ? usb_submit_urb+0x134f/0x1750
[  205.344531][  T111] usb 4-1: new high-speed USB device number 2 using dummy_hcd
[  205.329719][    C1]  ? handle_bug+0xec/0x180
[  205.329719][    C1]  ? exc_invalid_op+0x35/0x80
[  205.329719][    C1]  ? asm_exc_invalid_op+0x1a/0x20
[  205.329719][    C1]  ? __warn_printk+0x17a/0x310
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  cm109_urb_irq_callback+0x44b/0xb60
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  __usb_hcd_giveback_urb+0x2e4/0x6b0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  usb_hcd_giveback_urb+0x391/0x450
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  dummy_timer+0x1217/0x3540
[  205.329719][    C1]  ? debug_object_deactivate+0x2af/0x390
[  205.329719][    C1]  ? __pfx_mark_lock+0x10/0x10
[  205.329719][    C1]  ? find_held_lock+0x2d/0x120
[  205.329719][    C1]  ? __hrtimer_run_queues+0x529/0xc30
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  ? _raw_spin_unlock_irqrestore+0x58/0x70
[  205.329719][    C1]  ? _raw_spin_unlock_irqrestore+0x58/0x70
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  __hrtimer_run_queues+0x1b7/0xc30
[  205.329719][    C1]  ? __pfx___hrtimer_run_queues+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  hrtimer_run_softirq+0x17f/0x2e0
[  205.329719][    C1]  handle_softirqs+0x1bd/0x880
[  205.329719][    C1]  ? __dev_queue_xmit+0x1984/0x4060
[  205.329719][    C1]  do_softirq.part.0+0x8f/0xd0
[  205.329719][    C1]  </IRQ>
[  205.329719][    C1]  <TASK>
[  205.329719][    C1]  __local_bh_enable_ip+0x10e/0x130
[  205.329719][    C1]  ? __dev_queue_xmit+0x1984/0x4060
[  205.329719][    C1]  __dev_queue_xmit+0x1999/0x4060
[  205.329719][    C1]  ? __pfx___dev_queue_xmit+0x10/0x10
[  205.329719][    C1]  ? mark_lock+0xfe/0x12c0
[  205.329719][    C1]  ? __pfx_mark_lock+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? find_held_lock+0x2d/0x120
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? eth_header+0x118/0x1f0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? macvlan_hard_header+0xe1/0x160
[  205.329719][    C1]  neigh_resolve_output+0x527/0x8f0
[  205.329719][    C1]  ip6_finish_output2+0xb2b/0x22f0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __pfx_ip6_finish_output2+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? find_held_lock+0x2d/0x120
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ip6_finish_output+0x71a/0x1220
[  205.329719][    C1]  ip6_output+0x253/0x8e0
[  205.329719][    C1]  ? __pfx_ip6_output+0x10/0x10
[  205.329719][    C1]  ? ndisc_send_skb+0x58c/0x1a40
[  205.329719][    C1]  ? lockdep_rcu_suspicious+0x214/0x380
[  205.329719][    C1]  ? __pfx_ip6_finish_output+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? write_comp_data+0x29/0x80
[  205.329719][    C1]  ? __pfx_ip6_output+0x10/0x10
[  205.329719][    C1]  ndisc_send_skb+0xdce/0x1a40
[  205.329719][    C1]  ? __pfx_ndisc_send_skb+0x10/0x10
[  205.329719][    C1]  ? ndisc_alloc_skb+0x328/0x540
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? write_comp_data+0x29/0x80
[  205.329719][    C1]  ndisc_send_rs+0x12d/0x6d0
[  205.329719][    C1]  addrconf_dad_completed+0x438/0xdb0
[  205.329719][    C1]  ? __pfx_addrconf_dad_completed+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __local_bh_enable_ip+0xa4/0x130
[  205.329719][    C1]  ? addrconf_dad_work+0x830/0x1530
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  addrconf_dad_work+0x830/0x1530
[  205.329719][    C1]  ? __pfx_addrconf_dad_work+0x10/0x10
[  205.329719][    C1]  ? write_comp_data+0x29/0x80
[  205.329719][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.329719][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  process_scheduled_works+0x5c0/0x1aa0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __pfx_process_scheduled_works+0x10/0x10
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? assign_work+0x195/0x240
[  205.329719][    C1]  worker_thread+0x59f/0xcf0
[  205.329719][    C1]  ? __pfx_worker_thread+0x10/0x10
[  205.329719][    C1]  kthread+0x42a/0x880
[  205.329719][    C1]  ? __pfx_kthread+0x10/0x10
[  205.329719][    C1]  ? write_comp_data+0x29/0x80
[  205.329719][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.329719][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.329719][    C1]  ? __pfx_kthread+0x10/0x10
[  205.329719][    C1]  ret_from_fork+0x48/0x80
[  205.329719][    C1]  ? __pfx_kthread+0x10/0x10
[  205.329719][    C1]  ret_from_fork_asm+0x1a/0x30
[  205.329719][    C1]  </TASK>
[  205.329719][    C1] Kernel panic - not syncing: kernel: panic_on_warn set ...
[  205.329719][    C1] CPU: 1 UID: 0 PID: 13 Comm: kworker/u16:1 Not tainted 6.14.0 #2
[  205.329719][    C1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[  205.329719][    C1] Workqueue: ipv6_addrconf addrconf_dad_work
[  205.329719][    C1] Call Trace:
[  205.329719][    C1]  <IRQ>
[  205.329719][    C1]  dump_stack_lvl+0x3d/0x1b0
[  205.329719][    C1]  panic+0x70b/0x7c0
[  205.329719][    C1]  ? __pfx_panic+0x10/0x10
[  205.329719][    C1]  ? show_trace_log_lvl+0x284/0x390
[  205.329719][    C1]  ? check_panic_on_warn+0x1f/0xc0
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  check_panic_on_warn+0xb1/0xc0
[  205.329719][    C1]  __warn+0xf6/0x3d0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  report_bug+0x367/0x5c0
[  205.329719][    C1]  ? usb_submit_urb+0x134e/0x1750
[  205.329719][    C1]  ? usb_submit_urb+0x134f/0x1750
[  205.329719][    C1]  handle_bug+0xec/0x180
[  205.329719][    C1]  exc_invalid_op+0x35/0x80
[  205.329719][    C1]  asm_exc_invalid_op+0x1a/0x20
[  205.329719][    C1] RIP: 0010:usb_submit_urb+0x134e/0x1750
[  205.329719][    C1] Code: e8 07 19 a0 fa 84 db 0f 85 47 f5 ff ff e8 4a 17 a0 fa c6 05 cd 05 30 09 01 90 48 c7 c7 00 4f 2f 8c 4c 89 fe e8 43 11 60 fa 90 <0f> 0b 90 90 e9 21 f5 ff ff 48 89 7c 24 38 e8 1f 17 a0 fa 48 8b 7c
[  205.329719][    C1] RSP: 0018:ffffc900001f8ae0 EFLAGS: 00010082
[  205.329719][    C1] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817a1c9a
[  205.329719][    C1] RDX: 0000000000000000 RSI: ffff88801d2a8000 RDI: 0000000000000002
[  205.329719][    C1] RBP: ffff8880664cdb20 R08: 0000000000000000 R09: ffffed100fdc5182
[  205.329719][    C1] R10: ffffed100fdc5181 R11: ffff88807ee28c0b R12: 0000000000000046
[  205.329719][    C1] R13: ffff888055310858 R14: 00000000fffffff0 R15: ffff888046212a00
[  205.329719][    C1]  ? __warn_printk+0x17a/0x310
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  cm109_urb_irq_callback+0x44b/0xb60
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  __usb_hcd_giveback_urb+0x2e4/0x6b0
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  usb_hcd_giveback_urb+0x391/0x450
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  dummy_timer+0x1217/0x3540
[  205.329719][    C1]  ? debug_object_deactivate+0x2af/0x390
[  205.329719][    C1]  ? __pfx_mark_lock+0x10/0x10
[  205.329719][    C1]  ? find_held_lock+0x2d/0x120
[  205.329719][    C1]  ? __hrtimer_run_queues+0x529/0xc30
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  ? _raw_spin_unlock_irqrestore+0x58/0x70
[  205.329719][    C1]  ? _raw_spin_unlock_irqrestore+0x58/0x70
[  205.329719][    C1]  ? __pfx_dummy_timer+0x10/0x10
[  205.329719][    C1]  __hrtimer_run_queues+0x1b7/0xc30
[  205.329719][    C1]  ? __pfx___hrtimer_run_queues+0x10/0x10
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.329719][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.329719][    C1]  hrtimer_run_softirq+0x17f/0x2e0
[  205.329719][    C1]  handle_softirqs+0x1bd/0x880
[  205.329719][    C1]  ? __dev_queue_xmit+0x1984/0x4060
[  205.329719][    C1]  do_softirq.part.0+0x8f/0xd0
[  205.329719][    C1]  </IRQ>
[  205.329719][    C1]  <TASK>
[  205.329719][    C1]  __local_bh_enable_ip+0x10e/0x130
[  205.329719][    C1]  ? __dev_queue_xmit+0x1984/0x4060
[  205.329719][    C1]  __dev_queue_xmit+0x1999/0x4060
[  205.329719][    C1]  ? __pfx___dev_queue_xmit+0x10/0x10
[  205.329719][    C1]  ? mark_lock+0xfe/0x12c0
[  205.329719][    C1]  ? __pfx_mark_lock+0x10/0x10
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? find_held_lock+0x2d/0x120
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? eth_header+0x118/0x1f0
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? macvlan_hard_header+0xe1/0x160
[  205.614574][    C1]  neigh_resolve_output+0x527/0x8f0
[  205.614574][    C1]  ip6_finish_output2+0xb2b/0x22f0
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __pfx_ip6_finish_output2+0x10/0x10
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? find_held_lock+0x2d/0x120
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.614574][    C1]  ip6_finish_output+0x71a/0x1220
[  205.614574][    C1]  ip6_output+0x253/0x8e0
[  205.614574][    C1]  ? __pfx_ip6_output+0x10/0x10
[  205.614574][    C1]  ? ndisc_send_skb+0x58c/0x1a40
[  205.614574][    C1]  ? lockdep_rcu_suspicious+0x214/0x380
[  205.614574][    C1]  ? __pfx_ip6_finish_output+0x10/0x10
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? write_comp_data+0x29/0x80
[  205.614574][    C1]  ? __pfx_ip6_output+0x10/0x10
[  205.614574][    C1]  ndisc_send_skb+0xdce/0x1a40
[  205.614574][    C1]  ? __pfx_ndisc_send_skb+0x10/0x10
[  205.614574][    C1]  ? ndisc_alloc_skb+0x328/0x540
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? write_comp_data+0x29/0x80
[  205.614574][    C1]  ndisc_send_rs+0x12d/0x6d0
[  205.614574][    C1]  addrconf_dad_completed+0x438/0xdb0
[  205.614574][    C1]  ? __pfx_addrconf_dad_completed+0x10/0x10
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __local_bh_enable_ip+0xa4/0x130
[  205.614574][    C1]  ? addrconf_dad_work+0x830/0x1530
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  addrconf_dad_work+0x830/0x1530
[  205.614574][    C1]  ? __pfx_addrconf_dad_work+0x10/0x10
[  205.614574][    C1]  ? write_comp_data+0x29/0x80
[  205.614574][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.614574][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  process_scheduled_works+0x5c0/0x1aa0
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __pfx_process_scheduled_works+0x10/0x10
[  205.614574][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? __sanitizer_cov_trace_pc+0x20/0x50
[  205.614574][    C1]  ? srso_alias_return_thunk+0x5/0xfbef5
[  205.614574][    C1]  ? assign_work+0x195/0x240
[  205.614574][    C1]  worker_thread+0x59f/0xcf0
[  205.614574][    C1]  ? __pfx_worker_thread+0x10/0x10
[  205.614574][    C1]  kthread+0x42a/0x880
[  205.614574][    C1]  ? __pfx_kthread+0x10/0x10
[  205.614574][    C1]  ? write_comp_data+0x29/0x80
[  205.614574][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.614574][    C1]  ? _raw_spin_unlock_irq+0x23/0x50
[  205.614574][    C1]  ? __pfx_kthread+0x10/0x10
[  205.614574][    C1]  ret_from_fork+0x48/0x80
[  205.614574][    C1]  ? __pfx_kthread+0x10/0x10
[  205.614574][    C1]  ret_from_fork_asm+0x1a/0x30
[  205.614574][    C1]  </TASK>
[  205.614574][    C1] Shutting down cpus with NMI
[  205.614574][    C1] Kernel Offset: disabled
[  205.614574][    C1] Rebooting in 86400 seconds..

[-- Attachment #3: diff.jpg --]
[-- Type: image/jpeg, Size: 143791 bytes --]

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[胡焜]

> 
> 
> Hi Oliver,
> 
> Sorry for late, our servers have been down for a few days and we just managed to fix it today.
> 
> We retested the patch you provided, but we found that the issue still exists, but may be somewhat different from the call trace from the previous issue. I have provided a screenshot in diff form and the full call trace log in the attachment.
> 
> 
> ——————
> Thanks,
> Kun Hu
> 
> 
> <call trace.txt><diff.jpg>


Hi Oliver,

Was the information on these tests helpful to you? Please let me know if there are any tests you need.

—————
Best,
Kun

Re: WARNING in cm109_urb_irq_callback/usb_submit_urb

[Greg Kroah-Hartman]

On Thu, Mar 20, 2025 at 12:39:24PM +0800, 白烁冉 wrote:
> Dear Maintainers,
> 
> When using our customized Syzkaller to fuzz the latest Linux kernel, the following crash (94th)was triggered.
> 
> 
> HEAD commit: 6537cfb395f352782918d8ee7b7f10ba2cc3cbf2
> git tree: upstream
> Output:https://github.com/pghk13/Kernel-Bug/tree/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open
> Kernel config:https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/config.txt
> C reproducer:https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open/94repro.c
> Syzlang reproducer: https://github.com/pghk13/Kernel-Bug/blob/main/0305_6.14rc5/94-INFO_%20rcu%20detected%20stall%20in%20dcache_dir_open/94report
> 
> 
> The error occurs around line 379 of the urb.c file. The problem ends up in the cm109_urb_irq_callback function in the cm109.c file:In the cm109_urb_irq_callback function, the driver attempts to resubmit a URB that has not yet been processed. There may be a race condition in the driver that resubmits the URB in the URB completion callback, but the same URB may have already been committed to another location in the system. This issue seems to involve the creation of USB devices, the operation of TTY devices, and file descriptor copying. This complex interaction resulted in duplicate commits of the URB.
> We have reproduced this issue several times on 6.14-rc5 again.

Great!  Can you submit a fix for this as you have a reproducer you can
use to prove that it resolves the issue?

thanks,

greg k-h