All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	syzbot <syzbot+9b57a46bf1801ce2a2ca@syzkaller.appspotmail.com>,
	"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Linux USB Mailing List <linux-usb@vger.kernel.org>,
	Michal Kubecek <mkubecek@suse.cz>,
	syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] WARNING in hid_submit_ctrl/usb_submit_urb
Date: Tue, 31 Aug 2021 11:51:31 +0200	[thread overview]
Message-ID: <CAO-hwJ+i4MqOj0umUW9kFgYSZLt3QMb6hDZHQwb8AKH9pKxSTg@mail.gmail.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.2108241351490.15313@cbobk.fhfr.pm>

On Tue, Aug 24, 2021 at 1:54 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Fri, 20 Aug 2021, Alan Stern wrote:
>
> > > syzbot has tested the proposed patch and the reproducer did not trigger any issue:
> >
> > That's good to know.  Still, I suspect there's a better way of handling
> > this condition.
> >
> > In particular, does it make sense to accept descriptors for input or
> > feature reports with length zero?  I can't imagine what good such
> > reports would do.
>
> I quickly went through drivers + some hidraw users, and can't spot any use
> case for it.
>
> > On the other hand, I'm not familiar enough with the code to know the
> > right way to reject these descriptors and reports.  It looks like the
> > HID subsystem was not designed with this sort of check in mind.
> >
> > Benjamin and Jiri, what do you think?  Is it okay to allow descriptors
> > for zero-length reports and just pretend they have length 1 (as the
> > patch tested by syzbot did), or should we instead reject them during
> > probing?
>
> I think it's a good band-aid for 5.14 (or 5.14-stable if we don't make
> it), and if it turns out to break something (which I don't expect), than
> we can look into rejecting already during probe.
>
> Benjamin, is there a way to run this quickly through your HID regression
> testing machinery?
>

I have finally been able to test this patch:
- the testsuite is still passing (of course, this is not hid-core related)
- Logitech unify receivers are fine (according to the automated tests)
- Gaming mice with hidraw calls works (with libratbag in userspace)
- Wacom Intuos Pro still works (so the usbhid calls to enable the
tablet mode are still OK)

->
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

Alan, would you mind resending the patch with the various tags with a
commit description? (unless I missed it...)

Cheers,
Benjamin


  parent reply	other threads:[~2021-08-31  9:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-18 15:46 [syzbot] WARNING in hid_submit_ctrl/usb_submit_urb syzbot
2021-08-18  9:14 ` syzbot
2021-08-18 18:49   ` Alan Stern
2021-08-18 20:13     ` syzbot
2021-08-19 15:26       ` Alan Stern
2021-08-19 17:35         ` syzbot
2021-08-19 19:53           ` Alan Stern
2021-08-20  0:40             ` syzbot
2021-08-20 14:06               ` Alan Stern
2021-08-24 11:53                 ` Jiri Kosina
2021-08-24 12:34                   ` Benjamin Tissoires
2021-08-31  9:51                   ` Benjamin Tissoires [this message]
2021-08-31 13:34                     ` Alan Stern
2021-08-31 19:53                       ` Jiri Kosina
2021-09-01 15:38                     ` Alan Stern
2021-09-01 15:51                       ` Michal Kubecek
2021-09-01 16:35                         ` [PATCH 1/3] HID: usbhid: Fix flood of "control queue full" messages Alan Stern
2021-09-01 18:53                           ` Jiri Kosina
2021-08-24 11:50             ` [syzbot] WARNING in hid_submit_ctrl/usb_submit_urb Michal Kubecek
2021-08-30 19:22             ` Oleksandr Natalenko
2021-08-18 19:01   ` Alan Stern
2021-08-18 19:39 ` syzbot

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=CAO-hwJ+i4MqOj0umUW9kFgYSZLt3QMb6hDZHQwb8AKH9pKxSTg@mail.gmail.com \
    --to=benjamin.tissoires@redhat.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mkubecek@suse.cz \
    --cc=stern@rowland.harvard.edu \
    --cc=syzbot+9b57a46bf1801ce2a2ca@syzkaller.appspotmail.com \
    --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.