Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 7 Nov 2017 12:58:55 -0500 (EST)
From:   Alan Stern <stern@rowland.harvard.edu>
To:     Greg KH <gregkh@linuxfoundation.org>
cc:     syzbot 
        <bot+50d191d34989b5aa28596b0a2cb20c96f3ca4650@syzkaller.appspotmail.com>,
        <felipe.balbi@linux.intel.com>, <krinkin.m.u@gmail.com>,
        <linux-kernel@vger.kernel.org>, <linux-usb@vger.kernel.org>,
        <syzkaller-bugs@googlegroups.com>, <tiwai@suse.de>,
        <vskrishn@codeaurora.org>
Subject: Re: WARNING in usb_submit_urb
In-Reply-To: <20171107163556.GA13964@kroah.com>
Message-ID: <Pine.LNX.4.44L0.1711071252170.1395-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 7 Nov 2017, Greg KH wrote:

> On Tue, Nov 07, 2017 at 08:11:13AM -0800, syzbot wrote:
> > Hello,
> > 
> > syzkaller hit the following crash on
> > 36ef71cae353f88fd6e095e2aaa3e5953af1685d
> > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> > C reproducer is attached
> > syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> > for information about syzkaller reproducers
> 
> This is not a crash, you are doing a panic-on-warning, and you send
> invalid data to the kernel and it warned about it properly and kept on
> working :)
> 
> Perhaps maybe not a full WARN_ON() is to be done here?

I don't understand how this could have happened.  The raw log explains 
the problem:

> [   15.138822] usb usb1: BOGUS urb flags, 2 --> 0
> [   15.139498] ------------[ cut here ]------------
> [   15.139955] WARNING: CPU: 3 PID: 2986 at drivers/usb/core/urb.c:498 usb_submit_urb+0xeb9/0x10f0
...
> [   15.150280] RIP: 0010:usb_submit_urb+0xeb9/0x10f0
...
> [   15.155166]  proc_do_submiturb+0x1f53/0x3860

The "2 --> 0" means that proc_do_submiturb() tried to submit a control
URB (2 = PIPE_CONTROL) to an isochronous endpoint (0 = PIPE_ISOCHRONOUS).
But right near the start of the routine we have:

	switch (uurb->type) {
	case USBDEVFS_URB_TYPE_CONTROL:
		if (!usb_endpoint_xfer_control(&ep->desc))
			return -EINVAL;

So how was the warning triggered?

Alan Stern


From 1583460078035974129@xxx Wed Nov 08 01:40:07 +0000 2017
X-GM-THRID: 1583459420844146869
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread