[syzbot] WARNING in usb_new_device/usb_submit_urb

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 7652dd2c USB: core: Check buffer length matches wLength fo..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=1712b99dd00000
kernel config: https://syzkaller.appspot.com/x/.config?x=1206ee92dd3d988d
dashboard link: https://syzkaller.appspot.com/bug?extid=7dbcd9ff34dc4ed45240
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16b82e13d00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16ac418dd00000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7dbcd9...@syzkaller.appspotmail.com

usb 1-1: config 0 interface 186 altsetting 4 has a duplicate endpoint with address 0x8, skipping
usb 1-1: config 0 interface 166 has no altsetting 0
usb 1-1: config 0 interface 186 has no altsetting 0
------------[ cut here ]------------
usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType 80
WARNING: CPU: 1 PID: 2632 at drivers/usb/core/urb.c:410 usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410
Modules linked in:
CPU: 1 PID: 2632 Comm: kworker/1:2 Not tainted 5.13.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0x149d/0x18a0 drivers/usb/core/urb.c:410
Code: 7c 24 40 e8 c5 1f b3 fd 48 8b 7c 24 40 e8 6b a6 1b ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 80 0a 63 86 e8 15 ec fb 01 <0f> 0b e9 a5 ee ff ff e8 97 1f b3 fd 0f b6 1d db a7 34 05 31 ff 41
RSP: 0018:ffffc90000207680 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff8881182df058 RCX: 0000000000000000
RDX: ffff888114871b40 RSI: ffffffff812a6033 RDI: fffff52000040ec2
RBP: ffff88810cfffc80 R08: 0000000000000001 R09: 0000000000000000
R10: ffffffff814b998b R11: 0000000000000000 R12: ffff88810cfff6b8
R13: 0000000000000080 R14: 0000000080000280 R15: ffff88810e736f00
FS: 0000000000000000(0000) GS:ffff8881f6900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f13a00114f0 CR3: 0000000108807000 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
usb_get_string+0xa6/0x190 drivers/usb/core/message.c:837
usb_string_sub+0x35e/0x3d0 drivers/usb/core/message.c:883
usb_get_langid drivers/usb/core/message.c:913 [inline]
usb_string+0x1cc/0x540 drivers/usb/core/message.c:977
usb_cache_string+0x82/0x120 drivers/usb/core/message.c:1023
usb_enumerate_device drivers/usb/core/hub.c:2399 [inline]
usb_new_device+0x15b/0x7d0 drivers/usb/core/hub.c:2527
hub_port_connect drivers/usb/core/hub.c:5298 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5438 [inline]
port_event drivers/usb/core/hub.c:5584 [inline]
hub_event+0x2357/0x4330 drivers/usb/core/hub.c:5666
process_one_work+0x98d/0x1580 kernel/workqueue.c:2275
worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
kthread+0x38c/0x460 kernel/kthread.c:313
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294


---
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 syzk...@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

[Alan Stern]

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 7652dd2c

Index: usb-devel/drivers/usb/core/message.c
===================================================================
--- usb-devel.orig/drivers/usb/core/message.c
+++ usb-devel/drivers/usb/core/message.c
@@ -832,6 +832,8 @@ static int usb_get_string(struct usb_dev
int i;
int result;

+ if (size <= 0) /* No point in asking for no data */
+ return -EINVAL;
for (i = 0; i < 3; ++i) {
/* retry on length 0 or stall; some devices are flakey */
result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+7dbcd9...@syzkaller.appspotmail.com

Tested on:

commit: 7652dd2c USB: core: Check buffer length matches wLength fo..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git

kernel config: https://syzkaller.appspot.com/x/.config?x=363bc9f1c74dc789
dashboard link: https://syzkaller.appspot.com/bug?extid=7dbcd9ff34dc4ed45240
compiler:
patch: https://syzkaller.appspot.com/x/patch.diff?x=1091bcdbd00000

Note: testing is done by a robot and is best-effort only.

[Alan Stern]

The USB core has utility routines to retrieve various types of
descriptors. These routines will now provoke a WARN if they are asked
to retrieve 0 bytes (USB "receive" requests must not have zero
length), so avert this by checking the size argument at the start.

Reported-and-tested-by: syzbot+7dbcd9...@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <st...@rowland.harvard.edu>
CC: Johan Hovold <jo...@kernel.org>

---


[as1962]


drivers/usb/core/message.c | 4 ++++
1 file changed, 4 insertions(+)

Index: usb-devel/drivers/usb/core/message.c
===================================================================
--- usb-devel.orig/drivers/usb/core/message.c
+++ usb-devel/drivers/usb/core/message.c

@@ -783,6 +783,8 @@ int usb_get_descriptor(struct usb_device

int i;
int result;

+ if (size <= 0) /* No point in asking for no data */
+ return -EINVAL;

memset(buf, 0, size); /* Make sure we parse really received data */

for (i = 0; i < 3; ++i) {

@@ -832,6 +834,8 @@ static int usb_get_string(struct usb_dev

[Peter Chen]

On 21-06-04 12:10:39, Alan Stern wrote:
> The USB core has utility routines to retrieve various types of
> descriptors. These routines will now provoke a WARN if they are asked
> to retrieve 0 bytes (USB "receive" requests must not have zero
> length), so avert this by checking the size argument at the start.
>
> Reported-and-tested-by: syzbot+7dbcd9...@syzkaller.appspotmail.com
> Signed-off-by: Alan Stern <st...@rowland.harvard.edu>
> CC: Johan Hovold <jo...@kernel.org>
>
> ---
>
>
> [as1962]
>
>
> drivers/usb/core/message.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> Index: usb-devel/drivers/usb/core/message.c
> ===================================================================
> --- usb-devel.orig/drivers/usb/core/message.c
> +++ usb-devel/drivers/usb/core/message.c
> @@ -783,6 +783,8 @@ int usb_get_descriptor(struct usb_device
> int i;
> int result;
>
> + if (size <= 0) /* No point in asking for no data */
> + return -EINVAL;

One blank line after if {}

> memset(buf, 0, size); /* Make sure we parse really received data */
>
> for (i = 0; i < 3; ++i) {
> @@ -832,6 +834,8 @@ static int usb_get_string(struct usb_dev
> int i;
> int result;
>
> + if (size <= 0) /* No point in asking for no data */
> + return -EINVAL;

One blank line after if {}

> for (i = 0; i < 3; ++i) {
> /* retry on length 0 or stall; some devices are flakey */
> result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),

--

Thanks,
Peter Chen

[Johan Hovold]

On Fri, Jun 04, 2021 at 12:10:39PM -0400, Alan Stern wrote:
> The USB core has utility routines to retrieve various types of
> descriptors. These routines will now provoke a WARN if they are asked
> to retrieve 0 bytes (USB "receive" requests must not have zero
> length), so avert this by checking the size argument at the start.
>
> Reported-and-tested-by: syzbot+7dbcd9...@syzkaller.appspotmail.com
> Signed-off-by: Alan Stern <st...@rowland.harvard.edu>
> CC: Johan Hovold <jo...@kernel.org>
>
> ---
>
>
> [as1962]
>
>
> drivers/usb/core/message.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> Index: usb-devel/drivers/usb/core/message.c
> ===================================================================
> --- usb-devel.orig/drivers/usb/core/message.c
> +++ usb-devel/drivers/usb/core/message.c
> @@ -783,6 +783,8 @@ int usb_get_descriptor(struct usb_device
> int i;
> int result;
>
> + if (size <= 0) /* No point in asking for no data */
> + return -EINVAL;

I'd put a newline after the sanity checks as Peter suggested too, but
looks good otherwise so either way:

Reviewed-by: Johan Hovold <jo...@kernel.org>

> memset(buf, 0, size); /* Make sure we parse really received data */
>
> for (i = 0; i < 3; ++i) {
> @@ -832,6 +834,8 @@ static int usb_get_string(struct usb_dev
> int i;
> int result;
>
> + if (size <= 0) /* No point in asking for no data */
> + return -EINVAL;
> for (i = 0; i < 3; ++i) {
> /* retry on length 0 or stall; some devices are flakey */
> result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),

Johan

[Alan Stern]

The USB core has utility routines to retrieve various types of
descriptors. These routines will now provoke a WARN if they are asked
to retrieve 0 bytes (USB "receive" requests must not have zero
length), so avert this by checking the size argument at the start.

Reported-and-tested-by: syzbot+7dbcd9...@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <st...@rowland.harvard.edu>
CC: Johan Hovold <jo...@kernel.org>

---

v2: Added extra blank lines following the sanity tests.


[as1962b]


drivers/usb/core/message.c | 6 ++++++
1 file changed, 6 insertions(+)

Index: usb-devel/drivers/usb/core/message.c
===================================================================
--- usb-devel.orig/drivers/usb/core/message.c
+++ usb-devel/drivers/usb/core/message.c

@@ -783,6 +783,9 @@ int usb_get_descriptor(struct usb_device

int i;
int result;

+ if (size <= 0) /* No point in asking for no data */
+ return -EINVAL;

+

memset(buf, 0, size); /* Make sure we parse really received data */

for (i = 0; i < 3; ++i) {

@@ -832,6 +835,9 @@ static int usb_get_string(struct usb_dev

int i;
int result;

+ if (size <= 0) /* No point in asking for no data */
+ return -EINVAL;

+

[Johan Hovold]

On Mon, Jun 07, 2021 at 11:23:07AM -0400, Alan Stern wrote:
> The USB core has utility routines to retrieve various types of
> descriptors. These routines will now provoke a WARN if they are asked
> to retrieve 0 bytes (USB "receive" requests must not have zero
> length), so avert this by checking the size argument at the start.
>
> Reported-and-tested-by: syzbot+7dbcd9...@syzkaller.appspotmail.com
> Signed-off-by: Alan Stern <st...@rowland.harvard.edu>
> CC: Johan Hovold <jo...@kernel.org>
>
> ---
>
> v2: Added extra blank lines following the sanity tests.

Even better.

Reviewed-by: Johan Hovold <jo...@kernel.org>