From: Alan Stern <stern@rowland.harvard.edu>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
Jiri Kosina <jikos@kernel.org>
Cc: Michal Kubecek <mkubecek@suse.cz>,
Oleksandr Natalenko <oleksandr@natalenko.name>,
syzkaller-bugs@googlegroups.com, linux-input@vger.kernel.org,
Linux USB Mailing List <linux-usb@vger.kernel.org>
Subject: [PATCH 2/3] HID: usbhid: Fix warning caused by 0-length input reports
Date: Wed, 1 Sep 2021 12:36:00 -0400 [thread overview]
Message-ID: <20210901163600.GB404634@rowland.harvard.edu> (raw)
Syzbot found a warning caused by hid_submit_ctrl() submitting a
control request to transfer a 0-length input report:
usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType a1
(The warning message is a little difficult to understand. It means
that the control request claims to be for an IN transfer but this
contradicts the USB spec, which requires 0-length control transfers
always to be in the OUT direction.)
Now, a zero-length report isn't good for anything and there's no
reason for a device to have one, but the fuzzer likes to pick out
these weird edge cases. In the future, perhaps we will decide to
reject 0-length reports at probe time. For now, the simplest approach
for avoiding these warnings is to pretend that the report actually has
length 1.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: syzbot+9b57a46bf1801ce2a2ca@syzkaller.appspotmail.com
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: stable@vger.kernel.org
---
drivers/hid/usbhid/hid-core.c | 1 +
1 file changed, 1 insertion(+)
Index: usb-devel/drivers/hid/usbhid/hid-core.c
===================================================================
--- usb-devel.orig/drivers/hid/usbhid/hid-core.c
+++ usb-devel/drivers/hid/usbhid/hid-core.c
@@ -389,6 +389,7 @@ static int hid_submit_ctrl(struct hid_de
maxpacket = usb_maxpacket(hid_to_usb_dev(hid),
usbhid->urbctrl->pipe, 0);
if (maxpacket > 0) {
+ len += (len == 0); /* Don't allow 0-length reports */
len = DIV_ROUND_UP(len, maxpacket);
len *= maxpacket;
if (len > usbhid->bufsize)
reply other threads:[~2021-09-01 16:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20210901163600.GB404634@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=benjamin.tissoires@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mkubecek@suse.cz \
--cc=oleksandr@natalenko.name \
--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.