All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Greg KH <greg@kroah.com>
Cc: andreyknvl@google.com, <ingrassia@epigenesys.com>,
	USB list <linux-usb@vger.kernel.org>,
	<syzkaller-bugs@googlegroups.com>
Subject: [PATCH] USB: core: Fix misleading driver bug report
Date: Fri, 1 May 2020 16:07:28 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.2005011558590.903-100000@netrider.rowland.org> (raw)
In-Reply-To: <0000000000002a7b2905a4839206@google.com>

The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset.  Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a firmware update, for example).  While usb_ep0_reinit() is
running there is a brief period during which the pointers stored in
udev->ep_in[0] and udev->ep_out[0] are set to NULL, and if an URB is
submitted to ep0 during that period, usb_urb_ep_type_check() will
report it as a driver bug.  In the absence of those pointers, the
routine thinks that the endpoint doesn't exist.  The log message looks
like this:

------------[ cut here ]------------
usb 2-1: BOGUS urb xfer, pipe 2 != type 2
WARNING: CPU: 0 PID: 9241 at drivers/usb/core/urb.c:478
usb_submit_urb+0x1188/0x1460 drivers/usb/core/urb.c:478

Now, although submitting an URB while the device is being reset is a
questionable thing to do, it shouldn't count as a driver bug as severe
as submitting an URB for an endpoint that doesn't exist.  Indeed,
endpoint 0 always exists, even while the device is in its unconfigured
state.

To prevent these misleading driver bug reports, this patch updates
usb_disable_endpoint() to avoid clearing the ep_in[] and ep_out[]
pointers when the endpoint being disabled is ep0.  There's no danger
of leaving a stale pointer in place, because the usb_host_endpoint
structure being pointed to is stored permanently in udev->ep0; it
doesn't get deallocated until the entire usb_device structure does.

Reported-and-tested-by: syzbot+db339689b2101f6f6071@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

---

I don't think this needs to go into the stable kernels.  It only avoids
a dev_WARN() call, and the problem only occurs under fairly unlikely
circumstances.


[as1938]


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

Index: usb-devel/drivers/usb/core/message.c
===================================================================
--- usb-devel.orig/drivers/usb/core/message.c
+++ usb-devel/drivers/usb/core/message.c
@@ -1143,11 +1143,11 @@ void usb_disable_endpoint(struct usb_dev
 
 	if (usb_endpoint_out(epaddr)) {
 		ep = dev->ep_out[epnum];
-		if (reset_hardware)
+		if (reset_hardware && epnum != 0)
 			dev->ep_out[epnum] = NULL;
 	} else {
 		ep = dev->ep_in[epnum];
-		if (reset_hardware)
+		if (reset_hardware && epnum != 0)
 			dev->ep_in[epnum] = NULL;
 	}
 	if (ep) {


      reply	other threads:[~2020-05-01 20:07 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 13:04 WARNING in usbhid_raw_request/usb_submit_urb (3) syzbot
2020-04-01 20:49 ` syzbot
2020-04-02 15:35   ` Alan Stern
2020-04-02 15:53     ` syzbot
2020-04-02 15:57       ` Andrey Konovalov
2020-04-02 17:22         ` syzbot
2020-04-02 19:00           ` Alan Stern
2020-04-02 21:25             ` syzbot
2020-04-23  1:18               ` Alan Stern
2020-04-23  1:36                 ` syzbot
2020-04-23 16:37                   ` Alan Stern
2020-04-23 17:20                     ` syzbot
2020-04-23 18:54                       ` Alan Stern
2020-04-23 20:37                         ` syzbot
2020-04-23 21:09                           ` Alan Stern
2020-04-23 21:51                             ` syzbot
2020-04-24  1:00                               ` Alan Stern
2020-04-24  1:19                                 ` syzbot
2020-04-24  1:39                                   ` Alan Stern
2020-04-24  2:10                                     ` syzbot
2020-04-24 12:20                                       ` Alan Stern
2020-04-24 12:32                                         ` syzbot
2020-04-24 15:20                                           ` Alan Stern
2020-04-24 15:34                                             ` syzbot
2020-04-24 19:14                                               ` Alan Stern
2020-04-24 19:32                                                 ` syzbot
2020-04-25 20:25                                                   ` Alan Stern
2020-04-25 21:21                                                     ` syzbot
2020-04-29 20:11                                                       ` Alan Stern
2020-04-29 20:30                                                         ` syzbot
2020-04-29 23:41                                                           ` Alan Stern
2020-04-29 23:59                                                             ` syzbot
2020-04-30 14:58                                                               ` Alan Stern
2020-04-30 15:18                                                                 ` syzbot
2020-05-01 20:07                                                                   ` Alan Stern [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.2005011558590.903-100000@netrider.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=andreyknvl@google.com \
    --cc=greg@kroah.com \
    --cc=ingrassia@epigenesys.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.