[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y7hbY2ttx4ZLkKNY@rowland.harvard.edu>
Date: Fri, 6 Jan 2023 12:33:23 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: syzbot <syzbot+2a0e7abd24f1eb90ce25@...kaller.appspotmail.com>
Cc: Jakub Kicinski <kuba@...nel.org>, Oliver Neukum <oneukum@...e.com>,
gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org, mailhol.vincent@...adoo.fr,
mkl@...gutronix.de, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] WARNING in __usbnet_read_cmd/usb_submit_urb
On Fri, Jan 06, 2023 at 06:52:45AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 1b929c02afd3 Linux 6.2-rc1
> 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=128acc94480000
> kernel config: https://syzkaller.appspot.com/x/.config?x=19062640e84d2e8f
> dashboard link: https://syzkaller.appspot.com/bug?extid=2a0e7abd24f1eb90ce25
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>
> Unfortunately, I don't have any reproducer for this issue yet.
I don't know why not; the bug is easily repeatable.
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/22dc9b4a71a2/disk-1b929c02.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/3a88668bf3ce/vmlinux-1b929c02.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3ff0c2e45492/bzImage-1b929c02.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+2a0e7abd24f1eb90ce25@...kaller.appspotmail.com
>
> ------------[ cut here ]------------
> usb 3-1: BOGUS control dir, pipe 80003d80 doesn't match bRequestType c0
> WARNING: CPU: 1 PID: 2386 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a3/0x1880 drivers/usb/core/urb.c:411
> Call Trace:
> <TASK>
> usb_start_wait_urb+0x101/0x4b0 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
> __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010
> usbnet_read_cmd+0x92/0xf0 drivers/net/usb/usbnet.c:2068
> pl_vendor_req drivers/net/usb/plusb.c:60 [inline]
This is obviously a bug in plusb.c. The code is:
static inline int
pl_vendor_req(struct usbnet *dev, u8 req, u8 val, u8 index)
{
return usbnet_read_cmd(dev, req,
USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
val, index, NULL, 0);
}
Since the transfer length is 0 this should be a write, not a read. The
USB_DIR_IN value shouldn't be present, and the call should be to
usbnet_write_cmd().
There's a similar mistake in __usbnet_read_cmd(). The routine tests for
zero-length transfers, but when it finds one it merely avoids allocating
a transfer buffer instead of warning about a programming bug.
Alan Stern
Powered by blists - more mailing lists