lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ