From: Alan Stern <stern@rowland.harvard.edu>
To: Felipe Balbi <balbi@kernel.org>
Cc: Jacky.Cao@sony.com, <andreyknvl@google.com>,
<chunfeng.yun@mediatek.com>, USB list <linux-usb@vger.kernel.org>,
<syzkaller-bugs@googlegroups.com>
Subject: [PATCH] USB: gadget: Reject endpoints with 0 maxpacket value
Date: Mon, 28 Oct 2019 10:54:26 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.1910281052370.1485-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <00000000000030af530595acdd8b@google.com>
Endpoints with a maxpacket length of 0 are probably useless. They
can't transfer any data, and it's not at all unlikely that a UDC will
crash or hang when trying to handle a non-zero-length usb_request for
such an endpoint. Indeed, dummy-hcd gets a divide error when trying
to calculate the remainder of a transfer length by the maxpacket
value, as discovered by the syzbot fuzzer.
Currently the gadget core does not check for endpoints having a
maxpacket value of 0. This patch adds a check to usb_ep_enable(),
preventing such endpoints from being used.
As far as I know, none of the gadget drivers in the kernel tries to
create an endpoint with maxpacket = 0, but until now there has been
nothing to prevent userspace programs under gadgetfs or configfs from
doing it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: syzbot+8ab8bf161038a8768553@syzkaller.appspotmail.com
CC: <stable@vger.kernel.org>
---
[as1925]
drivers/usb/gadget/udc/core.c | 11 +++++++++++
1 file changed, 11 insertions(+)
Index: usb-devel/drivers/usb/gadget/udc/core.c
===================================================================
--- usb-devel.orig/drivers/usb/gadget/udc/core.c
+++ usb-devel/drivers/usb/gadget/udc/core.c
@@ -98,6 +98,17 @@ int usb_ep_enable(struct usb_ep *ep)
if (ep->enabled)
goto out;
+ /* UDC drivers can't handle endpoints with maxpacket size 0 */
+ if (usb_endpoint_maxp(ep->desc) == 0) {
+ /*
+ * We should log an error message here, but we can't call
+ * dev_err() because there's no way to find the gadget
+ * given only ep.
+ */
+ ret = -EINVAL;
+ goto out;
+ }
+
ret = ep->ops->enable(ep, ep->desc);
if (ret)
goto out;
next prev parent reply other threads:[~2019-10-28 14:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 13:58 divide error in dummy_timer syzbot
2019-10-24 15:04 ` Alan Stern
2019-10-24 15:22 ` syzbot
2019-10-24 17:05 ` Andrey Konovalov
2019-10-24 17:57 ` Alan Stern
2019-10-24 18:08 ` syzbot
2019-10-24 18:58 ` Alan Stern
2019-10-24 19:16 ` syzbot
2019-10-28 14:52 ` [PATCH] USB: Skip endpoints with 0 maxpacket length Alan Stern
2019-10-28 14:54 ` Alan Stern [this message]
2019-10-28 16:08 ` [PATCH] USB: gadget: Reject endpoints with 0 maxpacket value Greg KH
2019-10-29 8:38 ` Felipe Balbi
2019-10-24 18:55 ` divide error in dummy_timer Andrey Konovalov
2019-10-24 19:17 ` Alan Stern
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.1910281052370.1485-100000@iolanthe.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=Jacky.Cao@sony.com \
--cc=andreyknvl@google.com \
--cc=balbi@kernel.org \
--cc=chunfeng.yun@mediatek.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).