[syzbot] WARNING in do_proc_control/usb_submit_urb

[syzbot] WARNING in do_proc_control/usb_submit_urb

[syzbot]

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

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[Alan Stern]

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;
 

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[syzbot]

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

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[Alan Stern]

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

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[Alan Stern]

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);
>  

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[syzbot]

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:       

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[Alan Stern]

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

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[Johan Hovold]

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

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[Johan Hovold]

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

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[Alan Stern]

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);
 

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[Dmitry Vyukov]

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.

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[syzbot]

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.

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[Alan Stern]

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

Re: [syzbot] WARNING in do_proc_control/usb_submit_urb

[Dmitry Vyukov]

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