* Re: INFO: task hung in usb_bulk_msg [not found] <000000000000d3c499057536ce86@google.com> @ 2020-08-28 12:52 ` syzbot 2020-08-28 13:36 ` Andy Shevchenko 2020-08-29 1:24 ` Alan Stern 0 siblings, 2 replies; 5+ messages in thread From: syzbot @ 2020-08-28 12:52 UTC (permalink / raw) To: andriy.shevchenko, bigeasy, felipe.balbi, gregkh, joe, johan, kai.heng.feng, keescook, linux-kernel, linux-usb, rafael.j.wysocki, stern, syzkaller-bugs syzbot has found a reproducer for the following issue on: HEAD commit: 15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1052a669900000 kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994 dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101c328e900000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=155eff41900000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+7a7613e5ba9ae7bd15f9@syzkaller.appspotmail.com INFO: task syz-executor790:9958 blocked for more than 143 seconds. Not tainted 5.9.0-rc2-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor790 state:D stack:28240 pid: 9958 ppid: 6854 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:3778 [inline] __schedule+0x8e5/0x21e0 kernel/sched/core.c:4527 schedule+0xd0/0x2a0 kernel/sched/core.c:4602 schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1855 do_wait_for_common kernel/sched/completion.c:85 [inline] __wait_for_common kernel/sched/completion.c:106 [inline] wait_for_common kernel/sched/completion.c:117 [inline] wait_for_completion_timeout+0x15e/0x270 kernel/sched/completion.c:157 usb_start_wait_urb+0x144/0x2b0 drivers/usb/core/message.c:63 usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:254 do_proc_bulk+0x39b/0x710 drivers/usb/core/devio.c:1231 proc_bulk drivers/usb/core/devio.c:1268 [inline] usbdev_do_ioctl drivers/usb/core/devio.c:2542 [inline] usbdev_ioctl+0x586/0x3360 drivers/usb/core/devio.c:2708 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x44d089 Code: Bad RIP value. RSP: 002b:00007f70887dadb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000006dec48 RCX: 000000000044d089 RDX: 0000000020000000 RSI: 00000000c0185502 RDI: 0000000000000003 RBP: 00000000006dec40 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dec4c R13: 00007ffebdfc131f R14: 00007f70887db9c0 R15: 0000000000000064 Showing all locks held in the system: 1 lock held by ksoftirqd/1/16: #0: ffff8880ae735e18 (&rq->lock){-.-.}-{2:2}, at: rq_lock kernel/sched/sched.h:1292 [inline] #0: ffff8880ae735e18 (&rq->lock){-.-.}-{2:2}, at: __schedule+0x232/0x21e0 kernel/sched/core.c:4445 1 lock held by khungtaskd/1169: #0: ffffffff89bd6900 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:5825 1 lock held by in:imklog/6531: #0: ffff8880a83bab70 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:930 3 locks held by kworker/u4:0/6882: 1 lock held by syz-executor790/24330: #0: ffff8880ae635e18 (&rq->lock){-.-.}-{2:2}, at: rq_lock kernel/sched/sched.h:1292 [inline] #0: ffff8880ae635e18 (&rq->lock){-.-.}-{2:2}, at: __schedule+0x232/0x21e0 kernel/sched/core.c:4445 ============================================= NMI backtrace for cpu 0 CPU: 0 PID: 1169 Comm: khungtaskd Not tainted 5.9.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x18f/0x20d lib/dump_stack.c:118 nmi_cpu_backtrace.cold+0x70/0xb1 lib/nmi_backtrace.c:101 nmi_trigger_cpumask_backtrace+0x1b3/0x223 lib/nmi_backtrace.c:62 trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline] check_hung_uninterruptible_tasks kernel/hung_task.c:209 [inline] watchdog+0xd7d/0x1000 kernel/hung_task.c:295 kthread+0x3b5/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 6851 Comm: syz-executor790 Not tainted 5.9.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:get_timespec64+0x1b3/0x220 kernel/time/time.c:801 Code: 89 73 08 e8 8f f6 10 00 48 b8 00 00 00 00 00 fc ff df 49 c7 04 04 00 00 00 00 48 8b 44 24 58 65 48 2b 04 25 28 00 00 00 75 45 <48> 83 c4 60 44 89 e8 5b 5d 41 5c 41 5d 41 5e c3 e8 58 f6 10 00 45 RSP: 0018:ffffc90001667e20 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffc90001667ed0 RCX: ffffffff81634853 RDX: ffff8880a77381c0 RSI: ffffffff81634881 RDI: ffffc90001667ed8 RBP: 0000000000000000 R08: 00000000000f4240 R09: ffffc90001667e4f R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff920002ccfc4 R13: 0000000000000000 R14: 00000000000f4240 R15: 0000000000000000 FS: 000000000153e880(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004c6238 CR3: 00000000a93cd000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __do_sys_nanosleep kernel/time/hrtimer.c:1962 [inline] __se_sys_nanosleep kernel/time/hrtimer.c:1957 [inline] __x64_sys_nanosleep+0xaa/0x260 kernel/time/hrtimer.c:1957 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x44b800 Code: c0 5b 5d c3 66 0f 1f 44 00 00 8b 04 24 48 83 c4 18 5b 5d c3 66 0f 1f 44 00 00 83 3d b1 a0 29 00 00 75 14 b8 23 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 24 e4 fb ff c3 48 83 ec 08 e8 7a 43 00 00 RSP: 002b:00007ffebdfc1378 EFLAGS: 00000246 ORIG_RAX: 0000000000000023 RAX: ffffffffffffffda RBX: 00000000000025c4 RCX: 000000000044b800 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffebdfc1380 RBP: 000000000009bbed R08: 0000000000000001 R09: 000000000153e880 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffebdfc13e0 R13: 000000000040a140 R14: 0000000000000000 R15: 0000000000000000 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: INFO: task hung in usb_bulk_msg 2020-08-28 12:52 ` INFO: task hung in usb_bulk_msg syzbot @ 2020-08-28 13:36 ` Andy Shevchenko 2020-08-29 1:24 ` Alan Stern 1 sibling, 0 replies; 5+ messages in thread From: Andy Shevchenko @ 2020-08-28 13:36 UTC (permalink / raw) To: syzbot Cc: bigeasy, felipe.balbi, gregkh, joe, johan, kai.heng.feng, keescook, linux-kernel, linux-usb, rafael.j.wysocki, stern, syzkaller-bugs On Fri, Aug 28, 2020 at 05:52:16AM -0700, syzbot wrote: > syzbot has found a reproducer for the following issue on: > > HEAD commit: 15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1052a669900000 > kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994 > dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9 > compiler: gcc (GCC) 10.1.0-syz 20200507 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101c328e900000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=155eff41900000 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+7a7613e5ba9ae7bd15f9@syzkaller.appspotmail.com I have had hard times to understand the link between tty subsystem and this report. Also I'm wondering how 'Maintainers' column is formed in the dashboard view. And how the Cc list of this message in particular. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: INFO: task hung in usb_bulk_msg 2020-08-28 12:52 ` INFO: task hung in usb_bulk_msg syzbot 2020-08-28 13:36 ` Andy Shevchenko @ 2020-08-29 1:24 ` Alan Stern 2020-08-31 13:08 ` Andrey Konovalov 1 sibling, 1 reply; 5+ messages in thread From: Alan Stern @ 2020-08-29 1:24 UTC (permalink / raw) To: syzbot Cc: andriy.shevchenko, bigeasy, felipe.balbi, gregkh, joe, johan, kai.heng.feng, keescook, linux-kernel, linux-usb, rafael.j.wysocki, syzkaller-bugs On Fri, Aug 28, 2020 at 05:52:16AM -0700, syzbot wrote: > syzbot has found a reproducer for the following issue on: > > HEAD commit: 15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1052a669900000 > kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994 > dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9 > compiler: gcc (GCC) 10.1.0-syz 20200507 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101c328e900000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=155eff41900000 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+7a7613e5ba9ae7bd15f9@syzkaller.appspotmail.com > > INFO: task syz-executor790:9958 blocked for more than 143 seconds. > Not tainted 5.9.0-rc2-syzkaller #0 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > task:syz-executor790 state:D stack:28240 pid: 9958 ppid: 6854 flags:0x00004004 > Call Trace: > context_switch kernel/sched/core.c:3778 [inline] > __schedule+0x8e5/0x21e0 kernel/sched/core.c:4527 > schedule+0xd0/0x2a0 kernel/sched/core.c:4602 > schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1855 > do_wait_for_common kernel/sched/completion.c:85 [inline] > __wait_for_common kernel/sched/completion.c:106 [inline] > wait_for_common kernel/sched/completion.c:117 [inline] > wait_for_completion_timeout+0x15e/0x270 kernel/sched/completion.c:157 > usb_start_wait_urb+0x144/0x2b0 drivers/usb/core/message.c:63 > usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:254 > do_proc_bulk+0x39b/0x710 drivers/usb/core/devio.c:1231 > proc_bulk drivers/usb/core/devio.c:1268 [inline] > usbdev_do_ioctl drivers/usb/core/devio.c:2542 [inline] > usbdev_ioctl+0x586/0x3360 drivers/usb/core/devio.c:2708 I'm confused about this bug report. Here's the syz reproducer from the link listed above: # https://syzkaller.appspot.com/bug?id=bf172344c5f1d3487a4feff67c3dd30e08d5b635 # See https://goo.gl/kgGztJ for information about syzkaller reproducers. #{"threaded":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"netdev":true,"close_fds":true} r0 = syz_open_dev$usbfs(&(0x7f0000000040)='/dev/bus/usb/00#/00#\x00', 0x4000000000000071, 0x28081) r1 = socket$inet6(0xa, 0x2, 0x0) r2 = dup(r1) ioctl$PERF_EVENT_IOC_ENABLE(r2, 0x8912, 0x400200) socketpair$unix(0x1, 0x0, 0x0, &(0x7f0000000000)) ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, &(0x7f0000001140)={0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}) ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, &(0x7f0000000000)={0x1, 0x1}) As far as I can see, the only USB ioctls used in this test are USBDEVFS_CONTROL and USBDEVFS_CLEAR_HALT. Neither of those calls do_proc_bulk() or usb_bulk_msg(), so how did those routines end up in the stack trace? In fact, do_proc_bulk() is called only for USBDEVFS_BULK. But the test doesn't use that ioctl! What's going on? Am I missing part of the test? Alan Stern ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: INFO: task hung in usb_bulk_msg 2020-08-29 1:24 ` Alan Stern @ 2020-08-31 13:08 ` Andrey Konovalov 2020-10-14 16:25 ` Dmitry Vyukov 0 siblings, 1 reply; 5+ messages in thread From: Andrey Konovalov @ 2020-08-31 13:08 UTC (permalink / raw) To: Alan Stern, Dmitry Vyukov Cc: syzbot, andriy.shevchenko, bigeasy, Felipe Balbi, Greg Kroah-Hartman, Joe Perches, Johan Hovold, Kai Heng Feng, Kees Cook, LKML, USB list, rafael.j.wysocki, syzkaller-bugs On Sat, Aug 29, 2020 at 3:24 AM Alan Stern <stern@rowland.harvard.edu> wrote: > > On Fri, Aug 28, 2020 at 05:52:16AM -0700, syzbot wrote: > > syzbot has found a reproducer for the following issue on: > > > > HEAD commit: 15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1052a669900000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994 > > dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9 > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101c328e900000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=155eff41900000 > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+7a7613e5ba9ae7bd15f9@syzkaller.appspotmail.com > > > > INFO: task syz-executor790:9958 blocked for more than 143 seconds. > > Not tainted 5.9.0-rc2-syzkaller #0 > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > task:syz-executor790 state:D stack:28240 pid: 9958 ppid: 6854 flags:0x00004004 > > Call Trace: > > context_switch kernel/sched/core.c:3778 [inline] > > __schedule+0x8e5/0x21e0 kernel/sched/core.c:4527 > > schedule+0xd0/0x2a0 kernel/sched/core.c:4602 > > schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1855 > > do_wait_for_common kernel/sched/completion.c:85 [inline] > > __wait_for_common kernel/sched/completion.c:106 [inline] > > wait_for_common kernel/sched/completion.c:117 [inline] > > wait_for_completion_timeout+0x15e/0x270 kernel/sched/completion.c:157 > > usb_start_wait_urb+0x144/0x2b0 drivers/usb/core/message.c:63 > > usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:254 > > do_proc_bulk+0x39b/0x710 drivers/usb/core/devio.c:1231 > > proc_bulk drivers/usb/core/devio.c:1268 [inline] > > usbdev_do_ioctl drivers/usb/core/devio.c:2542 [inline] > > usbdev_ioctl+0x586/0x3360 drivers/usb/core/devio.c:2708 > > I'm confused about this bug report. > > Here's the syz reproducer from the link listed above: > > # > https://syzkaller.appspot.com/bug?id=bf172344c5f1d3487a4feff67c3dd30e08d5b635 > # See https://goo.gl/kgGztJ for information about syzkaller reproducers. > #{"threaded":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"netdev":true,"close_fds":true} > r0 = syz_open_dev$usbfs(&(0x7f0000000040)='/dev/bus/usb/00#/00#\x00', > 0x4000000000000071, 0x28081) > r1 = socket$inet6(0xa, 0x2, 0x0) > r2 = dup(r1) > ioctl$PERF_EVENT_IOC_ENABLE(r2, 0x8912, 0x400200) > socketpair$unix(0x1, 0x0, 0x0, &(0x7f0000000000)) > ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, &(0x7f0000001140)={0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}) > ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, &(0x7f0000000000)={0x1, 0x1}) > > As far as I can see, the only USB ioctls used in this test are > USBDEVFS_CONTROL and USBDEVFS_CLEAR_HALT. Neither of those calls > do_proc_bulk() or usb_bulk_msg(), so how did those routines end up in > the stack trace? > > In fact, do_proc_bulk() is called only for USBDEVFS_BULK. But the test > doesn't use that ioctl! > > What's going on? Am I missing part of the test? Hi Alan, Yeah, it's a bit confusing, sorry for that. Since syzkaller mutates the values that are passed into syscalls, it might mutate the cmd value of an ioctl. This results in a mismatch between the name of a syscall in syzkaller's notation, and the actual cmd value. In this case we have: ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, ...) where 0x8108551b == 2164806939, which is the value for USBDEVFS_DISCONNECT_CLAIM [1], and ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, ...) where 0xc0185502 == 3222820098, which is the value for USBDEVFS_BULK [2]. I remember Dmitry did some changes to this part, but I think syzkaller only avoids getting disabled ioctls during mutations. Dmitry, maybe it would make sense to avoid getting other known ioctls during mutations? Thanks! [1] https://github.com/google/syzkaller/blob/master/sys/linux/dev_bus_usb.txt.const#L13 [2] https://github.com/google/syzkaller/blob/master/sys/linux/dev_bus_usb.txt.const#L4 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: INFO: task hung in usb_bulk_msg 2020-08-31 13:08 ` Andrey Konovalov @ 2020-10-14 16:25 ` Dmitry Vyukov 0 siblings, 0 replies; 5+ messages in thread From: Dmitry Vyukov @ 2020-10-14 16:25 UTC (permalink / raw) To: Andrey Konovalov Cc: Alan Stern, syzbot, Andy Shevchenko, Sebastian Andrzej Siewior, Felipe Balbi, Greg Kroah-Hartman, Joe Perches, Johan Hovold, Kai Heng Feng, Kees Cook, LKML, USB list, rafael.j.wysocki, syzkaller-bugs, syzkaller On Mon, Aug 31, 2020 at 3:08 PM 'Andrey Konovalov' via syzkaller-bugs <syzkaller-bugs@googlegroups.com> wrote: > > On Sat, Aug 29, 2020 at 3:24 AM Alan Stern <stern@rowland.harvard.edu> wrote: > > > > On Fri, Aug 28, 2020 at 05:52:16AM -0700, syzbot wrote: > > > syzbot has found a reproducer for the following issue on: > > > > > > HEAD commit: 15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1052a669900000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9 > > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101c328e900000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=155eff41900000 > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+7a7613e5ba9ae7bd15f9@syzkaller.appspotmail.com > > > > > > INFO: task syz-executor790:9958 blocked for more than 143 seconds. > > > Not tainted 5.9.0-rc2-syzkaller #0 > > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > > > task:syz-executor790 state:D stack:28240 pid: 9958 ppid: 6854 flags:0x00004004 > > > Call Trace: > > > context_switch kernel/sched/core.c:3778 [inline] > > > __schedule+0x8e5/0x21e0 kernel/sched/core.c:4527 > > > schedule+0xd0/0x2a0 kernel/sched/core.c:4602 > > > schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1855 > > > do_wait_for_common kernel/sched/completion.c:85 [inline] > > > __wait_for_common kernel/sched/completion.c:106 [inline] > > > wait_for_common kernel/sched/completion.c:117 [inline] > > > wait_for_completion_timeout+0x15e/0x270 kernel/sched/completion.c:157 > > > usb_start_wait_urb+0x144/0x2b0 drivers/usb/core/message.c:63 > > > usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:254 > > > do_proc_bulk+0x39b/0x710 drivers/usb/core/devio.c:1231 > > > proc_bulk drivers/usb/core/devio.c:1268 [inline] > > > usbdev_do_ioctl drivers/usb/core/devio.c:2542 [inline] > > > usbdev_ioctl+0x586/0x3360 drivers/usb/core/devio.c:2708 > > > > I'm confused about this bug report. > > > > Here's the syz reproducer from the link listed above: > > > > # > > https://syzkaller.appspot.com/bug?id=bf172344c5f1d3487a4feff67c3dd30e08d5b635 > > # See https://goo.gl/kgGztJ for information about syzkaller reproducers. > > #{"threaded":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"netdev":true,"close_fds":true} > > r0 = syz_open_dev$usbfs(&(0x7f0000000040)='/dev/bus/usb/00#/00#\x00', > > 0x4000000000000071, 0x28081) > > r1 = socket$inet6(0xa, 0x2, 0x0) > > r2 = dup(r1) > > ioctl$PERF_EVENT_IOC_ENABLE(r2, 0x8912, 0x400200) > > socketpair$unix(0x1, 0x0, 0x0, &(0x7f0000000000)) > > ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, &(0x7f0000001140)={0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}) > > ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, &(0x7f0000000000)={0x1, 0x1}) > > > > As far as I can see, the only USB ioctls used in this test are > > USBDEVFS_CONTROL and USBDEVFS_CLEAR_HALT. Neither of those calls > > do_proc_bulk() or usb_bulk_msg(), so how did those routines end up in > > the stack trace? > > > > In fact, do_proc_bulk() is called only for USBDEVFS_BULK. But the test > > doesn't use that ioctl! > > > > What's going on? Am I missing part of the test? > > Hi Alan, > > Yeah, it's a bit confusing, sorry for that. Since syzkaller mutates > the values that are passed into syscalls, it might mutate the cmd > value of an ioctl. This results in a mismatch between the name of a > syscall in syzkaller's notation, and the actual cmd value. In this > case we have: > > ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, ...) > > where 0x8108551b == 2164806939, which is the value for > USBDEVFS_DISCONNECT_CLAIM [1], and > > ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, ...) > > where 0xc0185502 == 3222820098, which is the value for USBDEVFS_BULK [2]. > > I remember Dmitry did some changes to this part, but I think syzkaller > only avoids getting disabled ioctls during mutations. Dmitry, maybe it > would make sense to avoid getting other known ioctls during mutations? Agree, it would make sense. I've started working on it but wasn't able to finish. It also affects get/setsockopt, fcntl, prctl, bpf and others. In this more general context it turns out to be an interesting problem figuring out what is that exactly we don't want to mutate and to what values. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-10-14 16:26 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <000000000000d3c499057536ce86@google.com> 2020-08-28 12:52 ` INFO: task hung in usb_bulk_msg syzbot 2020-08-28 13:36 ` Andy Shevchenko 2020-08-29 1:24 ` Alan Stern 2020-08-31 13:08 ` Andrey Konovalov 2020-10-14 16:25 ` Dmitry Vyukov
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).