* WARNING in cm109_urb_irq_callback/usb_submit_urb
@ 2020-12-30 3:58 syzbot
2021-04-07 18:44 ` [syzbot] " syzbot
0 siblings, 1 reply; 13+ messages in thread
From: syzbot @ 2020-12-30 3:58 UTC (permalink / raw)
To: dmitry.torokhov, linux-input, linux-kernel, syzkaller-bugs, vulab
Hello,
syzbot found the following issue on:
HEAD commit: 5814bc2d Merge tag 'perf-tools-2020-12-24' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12f074db500000
kernel config: https://syzkaller.appspot.com/x/.config?x=bf519e1e96191576
dashboard link: https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
compiler: gcc (GCC) 10.1.0-syz 20200507
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2d6d691af5ab4b7e66df@syzkaller.appspotmail.com
cm109 2-1:0.0: cm109_urb_irq_callback: urb status -71
------------[ cut here ]------------
URB 0000000096f203b6 submitted while active
WARNING: CPU: 0 PID: 18262 at drivers/usb/core/urb.c:378 usb_submit_urb+0x128e/0x1560 drivers/usb/core/urb.c:378
Modules linked in:
CPU: 0 PID: 18262 Comm: syz-executor.5 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:usb_submit_urb+0x128e/0x1560 drivers/usb/core/urb.c:378
Code: 89 de e8 55 99 31 fc 84 db 0f 85 74 f4 ff ff e8 68 91 31 fc 4c 89 fe 48 c7 c7 a0 c6 02 8a c6 05 4b 89 28 08 01 e8 f6 1c 89 03 <0f> 0b e9 52 f4 ff ff c7 44 24 14 01 00 00 00 e9 09 f5 ff ff 41 be
RSP: 0018:ffffc900000079e8 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000040000 RSI: ffffffff815b94d5 RDI: fffff52000000f2f
RBP: ffff88802517c4c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815b792b R11: 0000000000000000 R12: 0000000000000012
R13: ffff88801e060058 R14: 00000000fffffff0 R15: ffff88801f2b6500
FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2f62d000 CR3: 000000002aba6000 CR4: 00000000001526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
cm109_urb_irq_callback+0x44f/0xaa0 drivers/input/misc/cm109.c:422
__usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1657
usb_hcd_giveback_urb+0x38c/0x430 drivers/usb/core/hcd.c:1728
dummy_timer+0x11f4/0x32a0 drivers/usb/gadget/udc/dummy_hcd.c:1971
call_timer_fn+0x1a5/0x710 kernel/time/timer.c:1417
expire_timers kernel/time/timer.c:1462 [inline]
__run_timers.part.0+0x692/0xa80 kernel/time/timer.c:1731
__run_timers kernel/time/timer.c:1712 [inline]
run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1744
__do_softirq+0x2bc/0xa77 kernel/softirq.c:343
asm_call_irq_on_stack+0xf/0x20
</IRQ>
__run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline]
run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline]
do_softirq_own_stack+0xaa/0xd0 arch/x86/kernel/irq_64.c:77
invoke_softirq kernel/softirq.c:226 [inline]
__irq_exit_rcu+0x17f/0x200 kernel/softirq.c:420
irq_exit_rcu+0x5/0x20 kernel/softirq.c:432
sysvec_apic_timer_interrupt+0x4d/0x100 arch/x86/kernel/apic/apic.c:1096
asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:628
RIP: 0010:check_kcov_mode+0x2c/0x40 kernel/kcov.c:174
Code: 05 09 a8 8e 7e 89 c2 81 e2 00 01 00 00 a9 00 01 ff 00 74 10 31 c0 85 d2 74 15 8b 96 cc 14 00 00 85 d2 74 0b 8b 86 a8 14 00 00 <39> f8 0f 94 c0 c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 31 c0
RSP: 0018:ffffc90014ebf628 EFLAGS: 00000246
RAX: 0000000000000000 RBX: 00000000000001fe RCX: 00000000000000aa
RDX: 0000000000000000 RSI: ffff888066450280 RDI: 0000000000000003
RBP: ffffea00004ca500 R08: 00000000000001fe R09: 00000000004ca500
R10: ffffffff819a63e0 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88802d906560 R14: 00000000000000aa R15: dffffc0000000000
write_comp_data kernel/kcov.c:218 [inline]
__sanitizer_cov_trace_cmp4+0x1c/0x70 kernel/kcov.c:258
release_pages+0x6f0/0x1d60 mm/swap.c:864
tlb_batch_pages_flush mm/mmu_gather.c:49 [inline]
tlb_flush_mmu_free mm/mmu_gather.c:242 [inline]
tlb_flush_mmu+0xe9/0x6b0 mm/mmu_gather.c:249
zap_pte_range mm/memory.c:1330 [inline]
zap_pmd_range mm/memory.c:1368 [inline]
zap_pud_range mm/memory.c:1397 [inline]
zap_p4d_range mm/memory.c:1418 [inline]
unmap_page_range+0x1a75/0x2640 mm/memory.c:1439
unmap_single_vma+0x198/0x300 mm/memory.c:1484
unmap_vmas+0x168/0x2e0 mm/memory.c:1516
exit_mmap+0x2b1/0x5a0 mm/mmap.c:3220
__mmput+0x122/0x470 kernel/fork.c:1083
mmput+0x53/0x60 kernel/fork.c:1104
exit_mm kernel/exit.c:500 [inline]
do_exit+0xa97/0x2a00 kernel/exit.c:810
do_group_exit+0x125/0x310 kernel/exit.c:920
get_signal+0x3e9/0x2160 kernel/signal.c:2770
arch_do_signal_or_restart+0x2a8/0x1eb0 arch/x86/kernel/signal.c:811
handle_signal_work kernel/entry/common.c:147 [inline]
exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
exit_to_user_mode_prepare+0x124/0x200 kernel/entry/common.c:201
__syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:302
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45e229
Code: Unable to access opcode bytes at RIP 0x45e1ff.
RSP: 002b:00007f2f8ae53cf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: 0000000000000001 RBX: 000000000119c030 RCX: 000000000045e229
RDX: 00000000000f4240 RSI: 0000000000000081 RDI: 000000000119c034
RBP: 000000000119c028 R08: 000000000000000e R09: 0000000000000000
R10: 0000000000000040 R11: 0000000000000246 R12: 000000000119c034
R13: 00007fffb9d4ee7f R14: 00007f2f8ae549c0 R15: 000000000119c034
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] WARNING in cm109_urb_irq_callback/usb_submit_urb
2020-12-30 3:58 WARNING in cm109_urb_irq_callback/usb_submit_urb syzbot
@ 2021-04-07 18:44 ` syzbot
0 siblings, 0 replies; 13+ messages in thread
From: syzbot @ 2021-04-07 18:44 UTC (permalink / raw)
To: dmitry.torokhov, gregkh, hdanton, isabel, linux-input,
linux-kernel, syzkaller-bugs, vulab
syzbot has found a reproducer for the following issue on:
HEAD commit: 2d743660 Merge branch 'fixes' of git://git.kernel.org/pub/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1548f46ad00000
kernel config: https://syzkaller.appspot.com/x/.config?x=f91155ccddaf919c
dashboard link: https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
compiler: Debian clang version 11.0.1-2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11d6cc96d00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=142de07ed00000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2d6d691af5ab4b7e66df@syzkaller.appspotmail.com
cm109 3-1:0.0: cm109_urb_irq_callback: urb status -71
------------[ cut here ]------------
URB 000000003185a218 submitted while active
WARNING: CPU: 0 PID: 8764 at drivers/usb/core/urb.c:378 usb_submit_urb+0xf7f/0x1550 drivers/usb/core/urb.c:378
Modules linked in:
CPU: 0 PID: 8764 Comm: systemd-udevd Not tainted 5.12.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:usb_submit_urb+0xf7f/0x1550 drivers/usb/core/urb.c:378
Code: 5c 41 5d 41 5e 41 5f 5d e9 4e 5b ff ff e8 39 a0 fc fb c6 05 b4 45 25 08 01 48 c7 c7 e0 6e 5f 8a 4c 89 e6 31 c0 e8 81 84 cb fb <0f> 0b e9 f8 f0 ff ff e8 15 a0 fc fb eb 05 e8 0e a0 fc fb bb a6 ff
RSP: 0018:ffffc900000079a8 EFLAGS: 00010046
RAX: 300ec5186f788100 RBX: ffff888020ad2508 RCX: ffff88803054d4c0
RDX: 0000000000000101 RSI: 0000000000000101 RDI: 0000000000000000
RBP: 0000000000000a20 R08: ffffffff8160b632 R09: ffffed1017383f1c
R10: ffffed1017383f1c R11: 0000000000000000 R12: ffff888020ad2500
R13: dffffc0000000000 R14: dffffc0000000000 R15: 0000000000000082
FS: 00007f65b13318c0(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffda12b4ff8 CR3: 0000000020ed4000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
cm109_urb_irq_callback+0x693/0xbf0 drivers/input/misc/cm109.c:422
__usb_hcd_giveback_urb+0x375/0x520 drivers/usb/core/hcd.c:1656
dummy_timer+0xa22/0x2e70 drivers/usb/gadget/udc/dummy_hcd.c:1971
call_timer_fn+0x91/0x160 kernel/time/timer.c:1431
expire_timers kernel/time/timer.c:1476 [inline]
__run_timers+0x6c0/0x8a0 kernel/time/timer.c:1745
run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1758
__do_softirq+0x318/0x714 kernel/softirq.c:345
invoke_softirq kernel/softirq.c:221 [inline]
__irq_exit_rcu+0x1d8/0x200 kernel/softirq.c:422
irq_exit_rcu+0x5/0x20 kernel/softirq.c:434
sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1100
</IRQ>
asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632
RIP: 0010:tomoyo_check_acl+0xb1/0x430 security/tomoyo/domain.c:173
Code: 85 05 03 00 00 48 8b 1c 24 4c 8b 23 49 39 dc 0f 84 14 02 00 00 0f 1f 40 00 49 8d 6c 24 18 48 89 e8 48 c1 e8 03 42 0f b6 04 28 <84> c0 0f 85 1d 01 00 00 0f b6 6d 00 31 ff 89 ee e8 4a df d8 fd 85
RSP: 0018:ffffc9000276fbb8 EFLAGS: 00000a02
RAX: 0000000000000000 RBX: ffff888011bcec90 RCX: ffff88803054d4c0
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
RBP: ffff888013c51118 R08: ffffffff83a03cb6 R09: ffffffff83a09b20
R10: 0000000000000003 R11: ffff88803054d4c0 R12: ffff888013c51100
R13: dffffc0000000000 R14: ffff888011bcec80 R15: 0000000000000000
tomoyo_path_permission+0x1af/0x370 security/tomoyo/file.c:586
tomoyo_path_perm+0x32f/0x570 security/tomoyo/file.c:838
security_inode_getattr+0xc0/0x140 security/security.c:1288
vfs_getattr fs/stat.c:131 [inline]
vfs_statx+0xe8/0x320 fs/stat.c:199
vfs_fstatat fs/stat.c:217 [inline]
vfs_lstat include/linux/fs.h:3240 [inline]
__do_sys_newlstat fs/stat.c:372 [inline]
__se_sys_newlstat fs/stat.c:366 [inline]
__x64_sys_newlstat+0x81/0xd0 fs/stat.c:366
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f65b01a3335
Code: 69 db 2b 00 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 83 ff 01 48 89 f0 77 30 48 89 c7 48 89 d6 b8 06 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 03 f3 c3 90 48 8b 15 31 db 2b 00 f7 d8 64 89
RSP: 002b:00007ffda12b2c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000006
RAX: ffffffffffffffda RBX: 000055b4a2eaa170 RCX: 00007f65b01a3335
RDX: 00007ffda12b2cb0 RSI: 00007ffda12b2cb0 RDI: 000055b4a2ea9170
RBP: 00007ffda12b2d70 R08: 00007f65b0462218 R09: 0000000000001010
R10: 00000000000001a0 R11: 0000000000000246 R12: 000055b4a2ea9170
R13: 000055b4a2ea9191 R14: 000055b4a2eb1fd6 R15: 000055b4a2eb1fe1
^ permalink raw reply [flat|nested] 13+ messages in thread
* WARNING in cm109_urb_irq_callback/usb_submit_urb
@ 2025-03-20 4:39 白烁冉
2025-03-20 13:35 ` Oliver Neukum
2025-03-20 13:40 ` Greg Kroah-Hartman
0 siblings, 2 replies; 13+ messages in thread
From: 白烁冉 @ 2025-03-20 4:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Dmitry Torokhov
Cc: Kun Hu, Jiaji Qin, linux-usb, linux-kernel, linux-input,
syzkaller
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: WARNING in cm109_urb_irq_callback/usb_submit_urb
2025-03-20 4:39 白烁冉
@ 2025-03-20 13:35 ` Oliver Neukum
2025-03-20 14:16 ` 胡焜
` (2 more replies)
2025-03-20 13:40 ` Greg Kroah-Hartman
1 sibling, 3 replies; 13+ messages in thread
From: Oliver Neukum @ 2025-03-20 13:35 UTC (permalink / raw)
To: 白烁冉, Greg Kroah-Hartman, Dmitry Torokhov
Cc: Kun Hu, Jiaji Qin, linux-usb, linux-kernel, linux-input,
syzkaller
[-- 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
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: WARNING in cm109_urb_irq_callback/usb_submit_urb
2025-03-20 13:35 ` Oliver Neukum
@ 2025-03-20 14:16 ` 胡焜
2025-03-20 14:25 ` Alan Stern
2025-04-01 9:40 ` 胡焜
2 siblings, 0 replies; 13+ messages in thread
From: 胡焜 @ 2025-03-20 14:16 UTC (permalink / raw)
To: Oliver Neukum
Cc: 白烁冉, Greg Kroah-Hartman, Dmitry Torokhov,
jjtan24@m.fudan.edu.cn, linux-usb, linux-kernel, linux-input,
syzkaller
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: WARNING in cm109_urb_irq_callback/usb_submit_urb
2025-03-20 13:35 ` Oliver Neukum
2025-03-20 14:16 ` 胡焜
@ 2025-03-20 14:25 ` Alan Stern
2025-03-20 15:42 ` Oliver Neukum
2025-04-01 9:40 ` 胡焜
2 siblings, 1 reply; 13+ messages in thread
From: Alan Stern @ 2025-03-20 14:25 UTC (permalink / raw)
To: Oliver Neukum
Cc: 白烁冉, Greg Kroah-Hartman, Dmitry Torokhov,
Kun Hu, Jiaji Qin, linux-usb, linux-kernel, linux-input,
syzkaller
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: WARNING in cm109_urb_irq_callback/usb_submit_urb
2025-03-20 14:25 ` Alan Stern
@ 2025-03-20 15:42 ` Oliver Neukum
2025-03-20 17:25 ` Alan Stern
0 siblings, 1 reply; 13+ messages in thread
From: Oliver Neukum @ 2025-03-20 15:42 UTC (permalink / raw)
To: Alan Stern, Oliver Neukum
Cc: 白烁冉, Greg Kroah-Hartman, Dmitry Torokhov,
Kun Hu, Jiaji Qin, linux-usb, linux-kernel, linux-input,
syzkaller
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: WARNING in cm109_urb_irq_callback/usb_submit_urb
2025-03-20 15:42 ` Oliver Neukum
@ 2025-03-20 17:25 ` Alan Stern
2025-03-27 11:42 ` Oliver Neukum
0 siblings, 1 reply; 13+ messages in thread
From: Alan Stern @ 2025-03-20 17:25 UTC (permalink / raw)
To: Oliver Neukum
Cc: 白烁冉, Greg Kroah-Hartman, Dmitry Torokhov,
Kun Hu, Jiaji Qin, linux-usb, linux-kernel, linux-input,
syzkaller
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: WARNING in cm109_urb_irq_callback/usb_submit_urb
2025-03-20 17:25 ` Alan Stern
@ 2025-03-27 11:42 ` Oliver Neukum
2025-03-27 14:27 ` Alan Stern
0 siblings, 1 reply; 13+ messages in thread
From: Oliver Neukum @ 2025-03-27 11:42 UTC (permalink / raw)
To: Alan Stern, Oliver Neukum
Cc: 白烁冉, Greg Kroah-Hartman, Dmitry Torokhov,
Kun Hu, Jiaji Qin, linux-usb, linux-kernel, linux-input,
syzkaller
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: WARNING in cm109_urb_irq_callback/usb_submit_urb
2025-03-27 11:42 ` Oliver Neukum
@ 2025-03-27 14:27 ` Alan Stern
0 siblings, 0 replies; 13+ messages in thread
From: Alan Stern @ 2025-03-27 14:27 UTC (permalink / raw)
To: Oliver Neukum
Cc: 白烁冉, Greg Kroah-Hartman, Dmitry Torokhov,
Kun Hu, Jiaji Qin, linux-usb, linux-kernel, linux-input,
syzkaller
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: WARNING in cm109_urb_irq_callback/usb_submit_urb
2025-03-20 13:35 ` Oliver Neukum
2025-03-20 14:16 ` 胡焜
2025-03-20 14:25 ` Alan Stern
@ 2025-04-01 9:40 ` 胡焜
2025-04-07 3:46 ` 胡焜
2 siblings, 1 reply; 13+ messages in thread
From: 胡焜 @ 2025-04-01 9:40 UTC (permalink / raw)
To: Oliver Neukum
Cc: 白烁冉, Dmitry Torokhov, jjtan24@m.fudan.edu.cn,
linux-usb, linux-kernel, linux-input, syzkaller
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: WARNING in cm109_urb_irq_callback/usb_submit_urb
2025-04-01 9:40 ` 胡焜
@ 2025-04-07 3:46 ` 胡焜
0 siblings, 0 replies; 13+ messages in thread
From: 胡焜 @ 2025-04-07 3:46 UTC (permalink / raw)
To: Oliver Neukum
Cc: 白烁冉, Dmitry Torokhov, jjtan24@m.fudan.edu.cn,
linux-usb, linux-kernel, linux-input, syzkaller
>
>
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: WARNING in cm109_urb_irq_callback/usb_submit_urb
2025-03-20 4:39 白烁冉
2025-03-20 13:35 ` Oliver Neukum
@ 2025-03-20 13:40 ` Greg Kroah-Hartman
1 sibling, 0 replies; 13+ messages in thread
From: Greg Kroah-Hartman @ 2025-03-20 13:40 UTC (permalink / raw)
To: 白烁冉
Cc: Dmitry Torokhov, Kun Hu, Jiaji Qin, linux-usb, linux-kernel,
linux-input, syzkaller
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2025-04-07 3:47 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-12-30 3:58 WARNING in cm109_urb_irq_callback/usb_submit_urb syzbot
2021-04-07 18:44 ` [syzbot] " syzbot
-- strict thread matches above, loose matches on Subject: below --
2025-03-20 4:39 白烁冉
2025-03-20 13:35 ` Oliver Neukum
2025-03-20 14:16 ` 胡焜
2025-03-20 14:25 ` Alan Stern
2025-03-20 15:42 ` Oliver Neukum
2025-03-20 17:25 ` Alan Stern
2025-03-27 11:42 ` Oliver Neukum
2025-03-27 14:27 ` Alan Stern
2025-04-01 9:40 ` 胡焜
2025-04-07 3:46 ` 胡焜
2025-03-20 13:40 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).
![[-- Attachment #3: diff.jpg --] [-- Type: image/jpeg, Size: 143791 bytes --]](../../3F7A182E-605F-4545-BF77-E739E7A624A4@m.fudan.edu.cn/3-diff.jpg){kind=link}