* [syzbot] WARNING in do_proc_control/usb_submit_urb @ 2021-07-10 11:11 syzbot 2021-07-10 14:50 ` Alan Stern 0 siblings, 1 reply; 14+ messages in thread From: syzbot @ 2021-07-10 11:11 UTC (permalink / raw) To: gregkh, johan, linux-kernel, linux-usb, mathias.nyman, stern, syzkaller-bugs Hello, syzbot found the following issue on: HEAD commit: ee268dee Add linux-next specific files for 20210707 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1067ddb4300000 kernel config: https://syzkaller.appspot.com/x/.config?x=59e1e3bbc3afca75 dashboard link: https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116443fc300000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=102541c4300000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+72af3105289dcb4c055b@syzkaller.appspotmail.com ------------[ cut here ]------------ usb usb2: BOGUS control dir, pipe 80000180 doesn't match bRequestType 80 WARNING: CPU: 0 PID: 8442 at drivers/usb/core/urb.c:410 usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410 Modules linked in: CPU: 1 PID: 8442 Comm: syz-executor261 Tainted: G W 5.13.0-next-20210707-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410 Code: 7c 24 40 e8 45 1e 20 fc 48 8b 7c 24 40 e8 6b 40 0c ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 99 27 8a e8 5a a4 91 03 <0f> 0b e9 a5 ee ff ff e8 17 1e 20 fc 0f b6 1d 21 86 02 08 31 ff 41 RSP: 0018:ffffc90002f5f9a8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888146fee058 RCX: 0000000000000000 RDX: ffff88801891b900 RSI: ffffffff815d7735 RDI: fffff520005ebf27 RBP: ffff88801f4523e8 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815d156e R11: 0000000000000000 R12: ffff88801c6aa8c0 R13: 0000000000000080 R14: 0000000080000180 R15: ffff8880205f3a00 FS: 0000000000977300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdf91ee0000 CR3: 0000000016427000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 do_proc_control+0x6c4/0x920 drivers/usb/core/devio.c:1141 proc_control drivers/usb/core/devio.c:1191 [inline] usbdev_do_ioctl drivers/usb/core/devio.c:2540 [inline] usbdev_ioctl+0x10e2/0x36c0 drivers/usb/core/devio.c:2713 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:1069 [inline] __se_sys_ioctl fs/ioctl.c:1055 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:1055 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x443489 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcf9b3e838 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004004a0 RCX: 0000000000443489 RDX: 0000000020000000 RSI: 00000000c0185500 RDI: 0000000000000003 RBP: 0000000000403030 R08: 0000000000000000 R09: 00000000004004a0 R10: 000000000000000f R11: 0000000000000246 R12: 00000000004030c0 R13: 0000000000000000 R14: 00000000004b1018 R15: 00000000004004a0 --- 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. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-10 11:11 [syzbot] WARNING in do_proc_control/usb_submit_urb syzbot @ 2021-07-10 14:50 ` Alan Stern 2021-07-10 22:58 ` syzbot 2021-07-11 15:53 ` Alan Stern 0 siblings, 2 replies; 14+ messages in thread From: Alan Stern @ 2021-07-10 14:50 UTC (permalink / raw) To: syzbot Cc: gregkh, johan, linux-kernel, linux-usb, mathias.nyman, syzkaller-bugs On Sat, Jul 10, 2021 at 04:11:15AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: ee268dee Add linux-next specific files for 20210707 > git tree: linux-next Is this an old version of syzbot? I thought it had been fixed up to give a real URL (one that "#syz test:" would accept) for the git tree and a 12-digit SHA-1 abbreviation for the HEAD commit. > console output: https://syzkaller.appspot.com/x/log.txt?x=1067ddb4300000 > kernel config: https://syzkaller.appspot.com/x/.config?x=59e1e3bbc3afca75 > dashboard link: https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116443fc300000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=102541c4300000 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+72af3105289dcb4c055b@syzkaller.appspotmail.com > > ------------[ cut here ]------------ > usb usb2: BOGUS control dir, pipe 80000180 doesn't match bRequestType 80 > WARNING: CPU: 0 PID: 8442 at drivers/usb/core/urb.c:410 usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410 > Modules linked in: > CPU: 1 PID: 8442 Comm: syz-executor261 Tainted: G W 5.13.0-next-20210707-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > RIP: 0010:usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410 > Code: 7c 24 40 e8 45 1e 20 fc 48 8b 7c 24 40 e8 6b 40 0c ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 99 27 8a e8 5a a4 91 03 <0f> 0b e9 a5 ee ff ff e8 17 1e 20 fc 0f b6 1d 21 86 02 08 31 ff 41 > RSP: 0018:ffffc90002f5f9a8 EFLAGS: 00010286 > RAX: 0000000000000000 RBX: ffff888146fee058 RCX: 0000000000000000 > RDX: ffff88801891b900 RSI: ffffffff815d7735 RDI: fffff520005ebf27 > RBP: ffff88801f4523e8 R08: 0000000000000000 R09: 0000000000000000 > R10: ffffffff815d156e R11: 0000000000000000 R12: ffff88801c6aa8c0 > R13: 0000000000000080 R14: 0000000080000180 R15: ffff8880205f3a00 > FS: 0000000000977300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007fdf91ee0000 CR3: 0000000016427000 CR4: 00000000001506e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 > usb_internal_control_msg drivers/usb/core/message.c:102 [inline] > usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 > do_proc_control+0x6c4/0x920 drivers/usb/core/devio.c:1141 > proc_control drivers/usb/core/devio.c:1191 [inline] > usbdev_do_ioctl drivers/usb/core/devio.c:2540 [inline] > usbdev_ioctl+0x10e2/0x36c0 drivers/usb/core/devio.c:2713 Apparently I forgot to fix the usbfs pathways. Alan Stern #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ee268dee Index: usb-devel/drivers/usb/core/devio.c =================================================================== --- usb-devel.orig/drivers/usb/core/devio.c +++ usb-devel/drivers/usb/core/devio.c @@ -1133,7 +1133,7 @@ static int do_proc_control(struct usb_de "wIndex=%04x wLength=%04x\n", ctrl->bRequestType, ctrl->bRequest, ctrl->wValue, ctrl->wIndex, ctrl->wLength); - if (ctrl->bRequestType & 0x80) { + if ((ctrl->bRequestType & USB_DIR_IN) && ctrl->wLength) { pipe = usb_rcvctrlpipe(dev, 0); snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, NULL, 0); @@ -1157,6 +1157,7 @@ static int do_proc_control(struct usb_de goto done; } } + ctrl->bRequestType &= ~USB_DIR_IN; pipe = usb_sndctrlpipe(dev, 0); snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, tbuf, ctrl->wLength); @@ -1579,6 +1580,13 @@ static int proc_do_submiturb(struct usb_ le16_to_cpu(dr->wIndex)); if (ret) goto error; + snoop(&ps->dev->dev, "control urb: bRequestType=%02x " + "bRequest=%02x wValue=%04x " + "wIndex=%04x wLength=%04x\n", + dr->bRequestType, dr->bRequest, + __le16_to_cpu(dr->wValue), + __le16_to_cpu(dr->wIndex), + __le16_to_cpu(dr->wLength)); uurb->buffer_length = le16_to_cpu(dr->wLength); uurb->buffer += 8; if ((dr->bRequestType & USB_DIR_IN) && uurb->buffer_length) { @@ -1587,16 +1595,10 @@ static int proc_do_submiturb(struct usb_ } else { is_in = false; uurb->endpoint &= ~USB_DIR_IN; + dr->bRequestType &= ~USB_DIR_IN; } if (is_in) allow_short = true; - snoop(&ps->dev->dev, "control urb: bRequestType=%02x " - "bRequest=%02x wValue=%04x " - "wIndex=%04x wLength=%04x\n", - dr->bRequestType, dr->bRequest, - __le16_to_cpu(dr->wValue), - __le16_to_cpu(dr->wIndex), - __le16_to_cpu(dr->wLength)); u = sizeof(struct usb_ctrlrequest); break; ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-10 14:50 ` Alan Stern @ 2021-07-10 22:58 ` syzbot 2021-07-11 0:36 ` Alan Stern 2021-07-11 15:53 ` Alan Stern 1 sibling, 1 reply; 14+ messages in thread From: syzbot @ 2021-07-10 22:58 UTC (permalink / raw) To: gregkh, johan, linux-kernel, linux-usb, mathias.nyman, stern, syzkaller-bugs Hello, syzbot has tested the proposed patch but the reproducer is still triggering an issue: BUG: sleeping function called from invalid context in lock_sock_nested BUG: sleeping function called from invalid context at net/core/sock.c:3159 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 8829, name: syz-executor.5 1 lock held by syz-executor.5/8829: #0: ffffffff8d2ecee0 (hci_sk_list.lock){++++}-{2:2}, at: hci_sock_dev_event+0x3db/0x660 net/bluetooth/hci_sock.c:763 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 1 PID: 8829 Comm: syz-executor.5 Not tainted 5.13.0-next-20210707-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:105 ___might_sleep.cold+0x1f1/0x237 kernel/sched/core.c:9171 lock_sock_nested+0x25/0x120 net/core/sock.c:3159 lock_sock include/net/sock.h:1613 [inline] hci_sock_dev_event+0x465/0x660 net/bluetooth/hci_sock.c:765 hci_unregister_dev+0x2fd/0x1130 net/bluetooth/hci_core.c:4033 vhci_release+0x70/0xe0 drivers/bluetooth/hci_vhci.c:340 __fput+0x288/0x920 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline] do_exit+0xbd4/0x2a60 kernel/exit.c:825 do_group_exit+0x125/0x310 kernel/exit.c:922 __do_sys_exit_group kernel/exit.c:933 [inline] __se_sys_exit_group kernel/exit.c:931 [inline] __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:931 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665d9 Code: Unable to access opcode bytes at RIP 0x4665af. RSP: 002b:00007ffd31aadb08 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007ffd31aae2c8 RCX: 00000000004665d9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 0000000000000000 R08: 0000000000000025 R09: 00007ffd31aae2c8 R10: 00000000ffffffff R11: 0000000000000246 R12: 00000000004bef54 R13: 0000000000000010 R14: 0000000000000000 R15: 0000000000400538 ====================================================== Tested on: commit: ee268dee Add linux-next specific files for 20210707 git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git console output: https://syzkaller.appspot.com/x/log.txt?x=159cf1e2300000 kernel config: https://syzkaller.appspot.com/x/.config?x=59e1e3bbc3afca75 dashboard link: https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b compiler: patch: https://syzkaller.appspot.com/x/patch.diff?x=163fd772300000 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-10 22:58 ` syzbot @ 2021-07-11 0:36 ` Alan Stern 0 siblings, 0 replies; 14+ messages in thread From: Alan Stern @ 2021-07-11 0:36 UTC (permalink / raw) To: syzbot Cc: gregkh, johan, linux-kernel, linux-usb, mathias.nyman, syzkaller-bugs On Sat, Jul 10, 2021 at 03:58:10PM -0700, syzbot wrote: > Hello, > > syzbot has tested the proposed patch but the reproducer is still triggering an issue: > BUG: sleeping function called from invalid context in lock_sock_nested This is clearly a different bug, so it looks like the patch does fix the original bug. I'll submit it after the end of the merge window. Alan Stern > BUG: sleeping function called from invalid context at net/core/sock.c:3159 > in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 8829, name: syz-executor.5 > 1 lock held by syz-executor.5/8829: > #0: ffffffff8d2ecee0 (hci_sk_list.lock){++++}-{2:2}, at: hci_sock_dev_event+0x3db/0x660 net/bluetooth/hci_sock.c:763 > Preemption disabled at: > [<0000000000000000>] 0x0 > CPU: 1 PID: 8829 Comm: syz-executor.5 Not tainted 5.13.0-next-20210707-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:105 > ___might_sleep.cold+0x1f1/0x237 kernel/sched/core.c:9171 > lock_sock_nested+0x25/0x120 net/core/sock.c:3159 > lock_sock include/net/sock.h:1613 [inline] > hci_sock_dev_event+0x465/0x660 net/bluetooth/hci_sock.c:765 > hci_unregister_dev+0x2fd/0x1130 net/bluetooth/hci_core.c:4033 > vhci_release+0x70/0xe0 drivers/bluetooth/hci_vhci.c:340 > __fput+0x288/0x920 fs/file_table.c:280 > task_work_run+0xdd/0x1a0 kernel/task_work.c:164 > exit_task_work include/linux/task_work.h:32 [inline] > do_exit+0xbd4/0x2a60 kernel/exit.c:825 > do_group_exit+0x125/0x310 kernel/exit.c:922 > __do_sys_exit_group kernel/exit.c:933 [inline] > __se_sys_exit_group kernel/exit.c:931 [inline] > __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:931 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x4665d9 > Code: Unable to access opcode bytes at RIP 0x4665af. > RSP: 002b:00007ffd31aadb08 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 > RAX: ffffffffffffffda RBX: 00007ffd31aae2c8 RCX: 00000000004665d9 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 > RBP: 0000000000000000 R08: 0000000000000025 R09: 00007ffd31aae2c8 > R10: 00000000ffffffff R11: 0000000000000246 R12: 00000000004bef54 > R13: 0000000000000010 R14: 0000000000000000 R15: 0000000000400538 > > ====================================================== > > > Tested on: > > commit: ee268dee Add linux-next specific files for 20210707 > git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > console output: https://syzkaller.appspot.com/x/log.txt?x=159cf1e2300000 > kernel config: https://syzkaller.appspot.com/x/.config?x=59e1e3bbc3afca75 > dashboard link: https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b > compiler: > patch: https://syzkaller.appspot.com/x/patch.diff?x=163fd772300000 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-10 14:50 ` Alan Stern 2021-07-10 22:58 ` syzbot @ 2021-07-11 15:53 ` Alan Stern 2021-07-11 16:07 ` syzbot 1 sibling, 1 reply; 14+ messages in thread From: Alan Stern @ 2021-07-11 15:53 UTC (permalink / raw) To: syzbot Cc: gregkh, johan, linux-kernel, linux-usb, mathias.nyman, syzkaller-bugs On Sat, Jul 10, 2021 at 10:50:03AM -0400, Alan Stern wrote: > On Sat, Jul 10, 2021 at 04:11:15AM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: ee268dee Add linux-next specific files for 20210707 > > git tree: linux-next > > Is this an old version of syzbot? I thought it had been fixed up to > give a real URL (one that "#syz test:" would accept) for the git > tree and a 12-digit SHA-1 abbreviation for the HEAD commit. Actually, on further thought it looks like only a one-line change is needed. Let's make sure it works. Alan Stern #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ee268dee > Index: usb-devel/drivers/usb/core/devio.c > =================================================================== > --- usb-devel.orig/drivers/usb/core/devio.c > +++ usb-devel/drivers/usb/core/devio.c > @@ -1133,7 +1133,7 @@ static int do_proc_control(struct usb_de > "wIndex=%04x wLength=%04x\n", > ctrl->bRequestType, ctrl->bRequest, ctrl->wValue, > ctrl->wIndex, ctrl->wLength); > - if (ctrl->bRequestType & 0x80) { > + if ((ctrl->bRequestType & USB_DIR_IN) && ctrl->wLength) { > pipe = usb_rcvctrlpipe(dev, 0); > snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, NULL, 0); > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-11 15:53 ` Alan Stern @ 2021-07-11 16:07 ` syzbot 2021-07-12 14:00 ` Alan Stern 0 siblings, 1 reply; 14+ messages in thread From: syzbot @ 2021-07-11 16:07 UTC (permalink / raw) To: gregkh, johan, linux-kernel, linux-usb, mathias.nyman, stern, syzkaller-bugs Hello, syzbot has tested the proposed patch but the reproducer is still triggering an issue: WARNING in do_proc_control/usb_submit_urb ------------[ cut here ]------------ usb usb2: BOGUS control dir, pipe 80000180 doesn't match bRequestType 80 WARNING: CPU: 0 PID: 10164 at drivers/usb/core/urb.c:410 usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410 Modules linked in: CPU: 1 PID: 10164 Comm: syz-executor.2 Tainted: G W 5.13.0-next-20210707-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410 Code: 7c 24 40 e8 45 1e 20 fc 48 8b 7c 24 40 e8 6b 40 0c ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 99 27 8a e8 5a a4 91 03 <0f> 0b e9 a5 ee ff ff e8 17 1e 20 fc 0f b6 1d 21 86 02 08 31 ff 41 RSP: 0018:ffffc9000a33f9a8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8881468f1058 RCX: 0000000000000000 RDX: ffff88802a830000 RSI: ffffffff815d7735 RDI: fffff52001467f27 RBP: ffff888142fe0578 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815d156e R11: 0000000000000000 R12: ffff888146811500 R13: 0000000000000080 R14: 0000000080000180 R15: ffff8880135f2700 FS: 00007f1b9bc83700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcfa7f3720 CR3: 000000003de67000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 do_proc_control+0x6c4/0x920 drivers/usb/core/devio.c:1141 proc_control drivers/usb/core/devio.c:1191 [inline] usbdev_do_ioctl drivers/usb/core/devio.c:2540 [inline] usbdev_ioctl+0x10e2/0x36c0 drivers/usb/core/devio.c:2713 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:1069 [inline] __se_sys_ioctl fs/ioctl.c:1055 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:1055 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f1b9bc83188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000056bf80 RCX: 00000000004665d9 RDX: 0000000020000000 RSI: 00000000c0185500 RDI: 0000000000000003 RBP: 00000000004bfcb9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056bf80 R13: 00007ffed6acd58f R14: 00007f1b9bc83300 R15: 0000000000022000 Tested on: commit: ee268dee Add linux-next specific files for 20210707 git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git console output: https://syzkaller.appspot.com/x/log.txt?x=13f337b4300000 kernel config: https://syzkaller.appspot.com/x/.config?x=59e1e3bbc3afca75 dashboard link: https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b compiler: ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-11 16:07 ` syzbot @ 2021-07-12 14:00 ` Alan Stern 2021-07-12 15:29 ` Johan Hovold 0 siblings, 1 reply; 14+ messages in thread From: Alan Stern @ 2021-07-12 14:00 UTC (permalink / raw) To: syzbot Cc: gregkh, johan, linux-kernel, linux-usb, mathias.nyman, syzkaller-bugs On Sun, Jul 11, 2021 at 09:07:09AM -0700, syzbot wrote: > Hello, > > syzbot has tested the proposed patch but the reproducer is still triggering an issue: > WARNING in do_proc_control/usb_submit_urb > > ------------[ cut here ]------------ > usb usb2: BOGUS control dir, pipe 80000180 doesn't match bRequestType 80 > WARNING: CPU: 0 PID: 10164 at drivers/usb/core/urb.c:410 usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410 > Modules linked in: > CPU: 1 PID: 10164 Comm: syz-executor.2 Tainted: G W 5.13.0-next-20210707-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > RIP: 0010:usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410 > Code: 7c 24 40 e8 45 1e 20 fc 48 8b 7c 24 40 e8 6b 40 0c ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 99 27 8a e8 5a a4 91 03 <0f> 0b e9 a5 ee ff ff e8 17 1e 20 fc 0f b6 1d 21 86 02 08 31 ff 41 > RSP: 0018:ffffc9000a33f9a8 EFLAGS: 00010286 > RAX: 0000000000000000 RBX: ffff8881468f1058 RCX: 0000000000000000 > RDX: ffff88802a830000 RSI: ffffffff815d7735 RDI: fffff52001467f27 > RBP: ffff888142fe0578 R08: 0000000000000000 R09: 0000000000000000 > R10: ffffffff815d156e R11: 0000000000000000 R12: ffff888146811500 > R13: 0000000000000080 R14: 0000000080000180 R15: ffff8880135f2700 > FS: 00007f1b9bc83700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007ffcfa7f3720 CR3: 000000003de67000 CR4: 00000000001506e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 > usb_internal_control_msg drivers/usb/core/message.c:102 [inline] > usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 > do_proc_control+0x6c4/0x920 drivers/usb/core/devio.c:1141 > proc_control drivers/usb/core/devio.c:1191 [inline] > usbdev_do_ioctl drivers/usb/core/devio.c:2540 [inline] > usbdev_ioctl+0x10e2/0x36c0 drivers/usb/core/devio.c:2713 I don't get this. It shouldn't be possible. The fact that the direction bit is set in both bRequestType and pipe means that the URB was submitted as a control-IN but had length 0. But the patch addresses exactly that case: --- usb-devel.orig/drivers/usb/core/devio.c +++ usb-devel/drivers/usb/core/devio.c @@ -1133,7 +1133,7 @@ static int do_proc_control(struct usb_de "wIndex=%04x wLength=%04x\n", ctrl->bRequestType, ctrl->bRequest, ctrl->wValue, ctrl->wIndex, ctrl->wLength); - if (ctrl->bRequestType & 0x80) { + if ((ctrl->bRequestType & USB_DIR_IN) && ctrl->wLength) { pipe = usb_rcvctrlpipe(dev, 0); snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, NULL, 0); and causes the kernel to handle it as a control-OUT instead. Johan, any ideas? Alan Stern ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-12 14:00 ` Alan Stern @ 2021-07-12 15:29 ` Johan Hovold 2021-07-12 15:50 ` Johan Hovold 0 siblings, 1 reply; 14+ messages in thread From: Johan Hovold @ 2021-07-12 15:29 UTC (permalink / raw) To: Alan Stern Cc: syzbot, gregkh, linux-kernel, linux-usb, mathias.nyman, syzkaller-bugs On Mon, Jul 12, 2021 at 10:00:04AM -0400, Alan Stern wrote: > On Sun, Jul 11, 2021 at 09:07:09AM -0700, syzbot wrote: > > Hello, > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue: > > WARNING in do_proc_control/usb_submit_urb > > > > ------------[ cut here ]------------ > > usb usb2: BOGUS control dir, pipe 80000180 doesn't match bRequestType 80 > > WARNING: CPU: 0 PID: 10164 at drivers/usb/core/urb.c:410 usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410 > > Modules linked in: > > CPU: 1 PID: 10164 Comm: syz-executor.2 Tainted: G W 5.13.0-next-20210707-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > RIP: 0010:usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410 > > Code: 7c 24 40 e8 45 1e 20 fc 48 8b 7c 24 40 e8 6b 40 0c ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 99 27 8a e8 5a a4 91 03 <0f> 0b e9 a5 ee ff ff e8 17 1e 20 fc 0f b6 1d 21 86 02 08 31 ff 41 > > RSP: 0018:ffffc9000a33f9a8 EFLAGS: 00010286 > > RAX: 0000000000000000 RBX: ffff8881468f1058 RCX: 0000000000000000 > > RDX: ffff88802a830000 RSI: ffffffff815d7735 RDI: fffff52001467f27 > > RBP: ffff888142fe0578 R08: 0000000000000000 R09: 0000000000000000 > > R10: ffffffff815d156e R11: 0000000000000000 R12: ffff888146811500 > > R13: 0000000000000080 R14: 0000000080000180 R15: ffff8880135f2700 > > FS: 00007f1b9bc83700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 00007ffcfa7f3720 CR3: 000000003de67000 CR4: 00000000001506e0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > Call Trace: > > usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 > > usb_internal_control_msg drivers/usb/core/message.c:102 [inline] > > usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 > > do_proc_control+0x6c4/0x920 drivers/usb/core/devio.c:1141 > > proc_control drivers/usb/core/devio.c:1191 [inline] > > usbdev_do_ioctl drivers/usb/core/devio.c:2540 [inline] > > usbdev_ioctl+0x10e2/0x36c0 drivers/usb/core/devio.c:2713 > > I don't get this. It shouldn't be possible. The fact that the > direction bit is set in both bRequestType and pipe means that the URB > was submitted as a control-IN but had length 0. But the patch addresses > exactly that case: > > --- usb-devel.orig/drivers/usb/core/devio.c > +++ usb-devel/drivers/usb/core/devio.c > @@ -1133,7 +1133,7 @@ static int do_proc_control(struct usb_de > "wIndex=%04x wLength=%04x\n", > ctrl->bRequestType, ctrl->bRequest, ctrl->wValue, > ctrl->wIndex, ctrl->wLength); > - if (ctrl->bRequestType & 0x80) { > + if ((ctrl->bRequestType & USB_DIR_IN) && ctrl->wLength) { > pipe = usb_rcvctrlpipe(dev, 0); > snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, NULL, 0); > > and causes the kernel to handle it as a control-OUT instead. > > Johan, any ideas? Did syzbot actually test the patch? I can't see how the direction bit of the pipe argument can be set with the above applied either. Johan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-12 15:29 ` Johan Hovold @ 2021-07-12 15:50 ` Johan Hovold 2021-07-12 16:14 ` Alan Stern 0 siblings, 1 reply; 14+ messages in thread From: Johan Hovold @ 2021-07-12 15:50 UTC (permalink / raw) To: Alan Stern Cc: syzbot, gregkh, linux-kernel, linux-usb, mathias.nyman, syzkaller-bugs On Mon, Jul 12, 2021 at 05:29:20PM +0200, Johan Hovold wrote: > On Mon, Jul 12, 2021 at 10:00:04AM -0400, Alan Stern wrote: > > On Sun, Jul 11, 2021 at 09:07:09AM -0700, syzbot wrote: > > > Hello, > > > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue: > > > WARNING in do_proc_control/usb_submit_urb > > I don't get this. It shouldn't be possible. The fact that the > > direction bit is set in both bRequestType and pipe means that the URB > > was submitted as a control-IN but had length 0. But the patch addresses > > exactly that case: > > > > --- usb-devel.orig/drivers/usb/core/devio.c > > +++ usb-devel/drivers/usb/core/devio.c > > @@ -1133,7 +1133,7 @@ static int do_proc_control(struct usb_de > > "wIndex=%04x wLength=%04x\n", > > ctrl->bRequestType, ctrl->bRequest, ctrl->wValue, > > ctrl->wIndex, ctrl->wLength); > > - if (ctrl->bRequestType & 0x80) { > > + if ((ctrl->bRequestType & USB_DIR_IN) && ctrl->wLength) { > > pipe = usb_rcvctrlpipe(dev, 0); > > snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, NULL, 0); > > > > and causes the kernel to handle it as a control-OUT instead. > > > > Johan, any ideas? > > Did syzbot actually test the patch? I can't see how the direction bit of > the pipe argument can be set with the above applied either. It looks like the second patch you submitted was hand-edited and still quoted. And looking at the dashboard it seems like no patch was applied for your second test attempt: https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b I've been bitten by something like this before when erroneously thinking that a test command could be submitted as a reply to a patch. Perhaps the report mail could include the patch tested or something so we don't spend time investigating syzbot interface failures. Johan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-12 15:50 ` Johan Hovold @ 2021-07-12 16:14 ` Alan Stern 2021-07-12 16:24 ` Dmitry Vyukov 2021-07-12 16:32 ` syzbot 0 siblings, 2 replies; 14+ messages in thread From: Alan Stern @ 2021-07-12 16:14 UTC (permalink / raw) To: Johan Hovold Cc: syzbot, gregkh, linux-kernel, linux-usb, mathias.nyman, syzkaller-bugs On Mon, Jul 12, 2021 at 05:50:41PM +0200, Johan Hovold wrote: > On Mon, Jul 12, 2021 at 05:29:20PM +0200, Johan Hovold wrote: > > On Mon, Jul 12, 2021 at 10:00:04AM -0400, Alan Stern wrote: > > > On Sun, Jul 11, 2021 at 09:07:09AM -0700, syzbot wrote: > > > > Hello, > > > > > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue: > > > > WARNING in do_proc_control/usb_submit_urb > > > > I don't get this. It shouldn't be possible. The fact that the > > > direction bit is set in both bRequestType and pipe means that the URB > > > was submitted as a control-IN but had length 0. But the patch addresses > > > exactly that case: > > > > > > --- usb-devel.orig/drivers/usb/core/devio.c > > > +++ usb-devel/drivers/usb/core/devio.c > > > @@ -1133,7 +1133,7 @@ static int do_proc_control(struct usb_de > > > "wIndex=%04x wLength=%04x\n", > > > ctrl->bRequestType, ctrl->bRequest, ctrl->wValue, > > > ctrl->wIndex, ctrl->wLength); > > > - if (ctrl->bRequestType & 0x80) { > > > + if ((ctrl->bRequestType & USB_DIR_IN) && ctrl->wLength) { > > > pipe = usb_rcvctrlpipe(dev, 0); > > > snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, NULL, 0); > > > > > > and causes the kernel to handle it as a control-OUT instead. > > > > > > Johan, any ideas? > > > > Did syzbot actually test the patch? I can't see how the direction bit of > > the pipe argument can be set with the above applied either. > > It looks like the second patch you submitted was hand-edited and still > quoted. > > And looking at the dashboard it seems like no patch was applied for your > second test attempt: > > https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b Yes, that explains it. Funny how easy it is to miss those "> " markings -- you just get too used to them. > I've been bitten by something like this before when erroneously thinking > that a test command could be submitted as a reply to a patch. > > Perhaps the report mail could include the patch tested or something so > we don't spend time investigating syzbot interface failures. Good idea. Anyway, here's the patch again, this time properly formatted. Hopefully now it will work. Alan Stern #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ee268dee Index: usb-devel/drivers/usb/core/devio.c =================================================================== --- usb-devel.orig/drivers/usb/core/devio.c +++ usb-devel/drivers/usb/core/devio.c @@ -1133,7 +1133,7 @@ static int do_proc_control(struct usb_de "wIndex=%04x wLength=%04x\n", ctrl->bRequestType, ctrl->bRequest, ctrl->wValue, ctrl->wIndex, ctrl->wLength); - if (ctrl->bRequestType & 0x80) { + if ((ctrl->bRequestType & USB_DIR_IN) && ctrl->wLength) { pipe = usb_rcvctrlpipe(dev, 0); snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, NULL, 0); ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-12 16:14 ` Alan Stern @ 2021-07-12 16:24 ` Dmitry Vyukov 2021-07-12 18:48 ` Alan Stern 2021-07-12 16:32 ` syzbot 1 sibling, 1 reply; 14+ messages in thread From: Dmitry Vyukov @ 2021-07-12 16:24 UTC (permalink / raw) To: Alan Stern Cc: Johan Hovold, syzbot, gregkh, linux-kernel, linux-usb, mathias.nyman, syzkaller-bugs On Mon, 12 Jul 2021 at 18:14, Alan Stern <stern@rowland.harvard.edu> wrote: > > > > > Hello, > > > > > > > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue: > > > > > WARNING in do_proc_control/usb_submit_urb > > > > > > I don't get this. It shouldn't be possible. The fact that the > > > > direction bit is set in both bRequestType and pipe means that the URB > > > > was submitted as a control-IN but had length 0. But the patch addresses > > > > exactly that case: > > > > > > > > --- usb-devel.orig/drivers/usb/core/devio.c > > > > +++ usb-devel/drivers/usb/core/devio.c > > > > @@ -1133,7 +1133,7 @@ static int do_proc_control(struct usb_de > > > > "wIndex=%04x wLength=%04x\n", > > > > ctrl->bRequestType, ctrl->bRequest, ctrl->wValue, > > > > ctrl->wIndex, ctrl->wLength); > > > > - if (ctrl->bRequestType & 0x80) { > > > > + if ((ctrl->bRequestType & USB_DIR_IN) && ctrl->wLength) { > > > > pipe = usb_rcvctrlpipe(dev, 0); > > > > snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, NULL, 0); > > > > > > > > and causes the kernel to handle it as a control-OUT instead. > > > > > > > > Johan, any ideas? > > > > > > Did syzbot actually test the patch? I can't see how the direction bit of > > > the pipe argument can be set with the above applied either. > > > > It looks like the second patch you submitted was hand-edited and still > > quoted. > > > > And looking at the dashboard it seems like no patch was applied for your > > second test attempt: > > > > https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b > > Yes, that explains it. Funny how easy it is to miss those "> " > markings -- you just get too used to them. > > > I've been bitten by something like this before when erroneously thinking > > that a test command could be submitted as a reply to a patch. > > > > Perhaps the report mail could include the patch tested or something so > > we don't spend time investigating syzbot interface failures. > > Good idea. The email always include the patch tested (as syzbot parsed it), see e.g. earlier reply in this thread: https://lore.kernel.org/lkml/00000000000074f06705c6ccd2a4@google.com/ > Anyway, here's the patch again, this time properly formatted. Hopefully > now it will work. syzbot parsed this patch successfully: https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b > Alan Stern > > > #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ee268dee > > Index: usb-devel/drivers/usb/core/devio.c > =================================================================== > --- usb-devel.orig/drivers/usb/core/devio.c > +++ usb-devel/drivers/usb/core/devio.c > @@ -1133,7 +1133,7 @@ static int do_proc_control(struct usb_de > "wIndex=%04x wLength=%04x\n", > ctrl->bRequestType, ctrl->bRequest, ctrl->wValue, > ctrl->wIndex, ctrl->wLength); > - if (ctrl->bRequestType & 0x80) { > + if ((ctrl->bRequestType & USB_DIR_IN) && ctrl->wLength) { > pipe = usb_rcvctrlpipe(dev, 0); > snoop_urb(dev, NULL, pipe, ctrl->wLength, tmo, SUBMIT, NULL, 0); > > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20210712161445.GA321728%40rowland.harvard.edu. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-12 16:24 ` Dmitry Vyukov @ 2021-07-12 18:48 ` Alan Stern 2021-07-15 7:19 ` Dmitry Vyukov 0 siblings, 1 reply; 14+ messages in thread From: Alan Stern @ 2021-07-12 18:48 UTC (permalink / raw) To: Dmitry Vyukov Cc: Johan Hovold, syzbot, gregkh, linux-kernel, linux-usb, mathias.nyman, syzkaller-bugs On Mon, Jul 12, 2021 at 06:24:43PM +0200, Dmitry Vyukov wrote: > On Mon, 12 Jul 2021 at 18:14, Alan Stern <stern@rowland.harvard.edu> wrote: > > > It looks like the second patch you submitted was hand-edited and still > > > quoted. > > > > > > And looking at the dashboard it seems like no patch was applied for your > > > second test attempt: > > > > > > https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b > > > > Yes, that explains it. Funny how easy it is to miss those "> " > > markings -- you just get too used to them. > > > > > I've been bitten by something like this before when erroneously thinking > > > that a test command could be submitted as a reply to a patch. > > > > > > Perhaps the report mail could include the patch tested or something so > > > we don't spend time investigating syzbot interface failures. > > > > Good idea. > > The email always include the patch tested (as syzbot parsed it), see > e.g. earlier reply in this thread: > https://lore.kernel.org/lkml/00000000000074f06705c6ccd2a4@google.com/ The email doesn't include the patch; it includes a _link_ to the patch. And the email does not contain any indication when no patch was parsed, other than the missing "patch:" link -- which is not particularly obvious if you aren't looking for it specifically: https://marc.info/?l=linux-usb&m=162602190812912&w=2 > > Anyway, here's the patch again, this time properly formatted. Hopefully > > now it will work. > > syzbot parsed this patch successfully: > https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b Yes, and it worked. Time to submit it. Alan Stern ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-12 18:48 ` Alan Stern @ 2021-07-15 7:19 ` Dmitry Vyukov 0 siblings, 0 replies; 14+ messages in thread From: Dmitry Vyukov @ 2021-07-15 7:19 UTC (permalink / raw) To: Alan Stern Cc: Johan Hovold, syzbot, gregkh, linux-kernel, linux-usb, mathias.nyman, syzkaller-bugs On Mon, 12 Jul 2021 at 20:48, Alan Stern <stern@rowland.harvard.edu> wrote: > > On Mon, Jul 12, 2021 at 06:24:43PM +0200, Dmitry Vyukov wrote: > > On Mon, 12 Jul 2021 at 18:14, Alan Stern <stern@rowland.harvard.edu> wrote: > > > > > It looks like the second patch you submitted was hand-edited and still > > > > quoted. > > > > > > > > And looking at the dashboard it seems like no patch was applied for your > > > > second test attempt: > > > > > > > > https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b > > > > > > Yes, that explains it. Funny how easy it is to miss those "> " > > > markings -- you just get too used to them. > > > > > > > I've been bitten by something like this before when erroneously thinking > > > > that a test command could be submitted as a reply to a patch. > > > > > > > > Perhaps the report mail could include the patch tested or something so > > > > we don't spend time investigating syzbot interface failures. > > > > > > Good idea. > > > > The email always include the patch tested (as syzbot parsed it), see > > e.g. earlier reply in this thread: > > https://lore.kernel.org/lkml/00000000000074f06705c6ccd2a4@google.com/ > > The email doesn't include the patch; it includes a _link_ to the patch. > > And the email does not contain any indication when no patch was parsed, > other than the missing "patch:" link -- which is not particularly > obvious if you aren't looking for it specifically: > > https://marc.info/?l=linux-usb&m=162602190812912&w=2 I've filed https://github.com/google/syzkaller/issues/2668 for explicitly saying that there was no patch. Using links instead of attachments is intentional, initially syzbot attached lots of things to emails and lots of users complained about huge emails. So now all additional info goes via links. > > > Anyway, here's the patch again, this time properly formatted. Hopefully > > > now it will work. > > > > syzbot parsed this patch successfully: > > https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b > > Yes, and it worked. Time to submit it. > > Alan Stern ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [syzbot] WARNING in do_proc_control/usb_submit_urb 2021-07-12 16:14 ` Alan Stern 2021-07-12 16:24 ` Dmitry Vyukov @ 2021-07-12 16:32 ` syzbot 1 sibling, 0 replies; 14+ messages in thread From: syzbot @ 2021-07-12 16:32 UTC (permalink / raw) To: gregkh, johan, linux-kernel, linux-usb, mathias.nyman, stern, syzkaller-bugs Hello, syzbot has tested the proposed patch and the reproducer did not trigger any issue: Reported-and-tested-by: syzbot+72af3105289dcb4c055b@syzkaller.appspotmail.com Tested on: commit: ee268dee Add linux-next specific files for 20210707 git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git kernel config: https://syzkaller.appspot.com/x/.config?x=59e1e3bbc3afca75 dashboard link: https://syzkaller.appspot.com/bug?extid=72af3105289dcb4c055b compiler: patch: https://syzkaller.appspot.com/x/patch.diff?x=14b945d8300000 Note: testing is done by a robot and is best-effort only. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-07-15 7:19 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-10 11:11 [syzbot] WARNING in do_proc_control/usb_submit_urb syzbot 2021-07-10 14:50 ` Alan Stern 2021-07-10 22:58 ` syzbot 2021-07-11 0:36 ` Alan Stern 2021-07-11 15:53 ` Alan Stern 2021-07-11 16:07 ` syzbot 2021-07-12 14:00 ` Alan Stern 2021-07-12 15:29 ` Johan Hovold 2021-07-12 15:50 ` Johan Hovold 2021-07-12 16:14 ` Alan Stern 2021-07-12 16:24 ` Dmitry Vyukov 2021-07-12 18:48 ` Alan Stern 2021-07-15 7:19 ` Dmitry Vyukov 2021-07-12 16:32 ` syzbot
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.