linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Wu <peter@lekensteyn.nl>
To: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
	Nestor Lopez Casado <nlopezcasad@logitech.com>,
	linux-input <linux-input@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] HID: logitech-{dj,hidpp}: check report length
Date: Tue, 16 Dec 2014 16:20:58 +0100	[thread overview]
Message-ID: <9001812.kk9brShn75@al> (raw)
In-Reply-To: <CAN+gG=HWqpy6MUfWvwBavk+EkmwbBiCCN0L1_i8H61WYRU0yGw@mail.gmail.com>

On Tuesday 16 December 2014 09:53:07 Benjamin Tissoires wrote:
> On Mon, Dec 15, 2014 at 7:50 PM, Peter Wu <peter@lekensteyn.nl> wrote:
> > Malicious USB devices can send bogus reports smaller than the expected
> > buffer size. Ensure that the length is valid to avoid reading out of
> > bounds.
> >
> > For the old WTP, I do not have a HID descriptor so just check for the
> > minimum length in hidpp_raw_event (this can be changed to an inequality
> > later).
> 
> Actually you have it :)
> All the DJ devices share the same report descriptors as they are
> provided by hid-logitech-dj :)

I see, I thought it was read from the hardware, but that probably
applies to the other interfaces. Looks like the report should have a
length of (16 + 12 * 2 + 8 + 8) / 8 = 7 bytes, correct?

> Anyway, the problem here would be with the bluetooth touchpad T651
> which sends its raw events over teh mouse (0x02) collection (hint:
> there is a "< 21" in wtp_raw_event :-P )

Huh, how can that be allowed if the mouse descriptor accept less? Does
the bluetooth layer pad the report somehow?

> >
> > Signed-off-by: Peter Wu <peter@lekensteyn.nl>
> > ---
> > Hi,
> >
> > If you know that the WTP report (ID 2) has a length of 2, then you can change
> > "<" to "!=" and remove the paragraph from the commit message.
> 
> "<" should be kept for the reason above.
> 
> >
> > Kind regards,
> > Peter
> > ---
> >  drivers/hid/hid-logitech-dj.c    | 16 +++++++++++++++-
> >  drivers/hid/hid-logitech-hidpp.c | 12 +++++++++---
> >  2 files changed, 24 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> > index c917ab6..5bc6d80 100644
> > --- a/drivers/hid/hid-logitech-dj.c
> > +++ b/drivers/hid/hid-logitech-dj.c
> > @@ -962,10 +962,24 @@ static int logi_dj_raw_event(struct hid_device *hdev,
> >
> >         switch (data[0]) {
> >         case REPORT_ID_DJ_SHORT:
> > +               if (size != DJREPORT_SHORT_LENGTH) {
> > +                       dev_err(&hdev->dev, "DJ report of bad size (%d)", size);
> > +                       return false;
> > +               }
> >                 return logi_dj_dj_event(hdev, report, data, size);
> >         case REPORT_ID_HIDPP_SHORT:
> > -               /* intentional fallthrough */
> > +               if (size != HIDPP_REPORT_SHORT_LENGTH) {
> > +                       dev_err(&hdev->dev,
> > +                               "Short HID++ report of bad size (%d)", size);
> > +                       return false;
> > +               }
> > +               return logi_dj_hidpp_event(hdev, report, data, size);
> >         case REPORT_ID_HIDPP_LONG:
> > +               if (size != HIDPP_REPORT_LONG_LENGTH) {
> > +                       dev_err(&hdev->dev,
> > +                               "Long HID++ report of bad size (%d)", size);
> > +                       return false;
> > +               }
> 
> This hunk is good to me.
> 
> >                 return logi_dj_hidpp_event(hdev, report, data, size);
> >         }
> >
> > diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> > index ae23dec..2315358 100644
> > --- a/drivers/hid/hid-logitech-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -992,11 +992,17 @@ static int hidpp_raw_event(struct hid_device *hdev, struct hid_report *report,
> >                         return 1;
> >                 }
> >                 return hidpp_raw_hidpp_event(hidpp, data, size);
> > +       case 0x02:
> > +               if (size < 2) {
> > +                       hid_err(hdev, "Received HID report of bad size (%d)",
> > +                               size);
> > +                       return 1;
> > +               }
> > +               if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
> > +                       return wtp_raw_event(hdev, data, size);
> > +               return 1;
> >         }
> >
> > -       if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
> > -               return wtp_raw_event(hdev, data, size);
> 
> This one is OK, but I don't like it.
> 
> wtp_raw_event also expects long hid++ reports, and I'd prefer having
> the raw_event() callback first checking on the generic hid++ reports,
> and then addressing the various subclasses of devices.
> After a better look at the code, it occurs that the actual code is
> already pretty messed up.
> wtp_raw_event() is called both in the generic hidpp_raw_event() and in
> the specific hidpp_raw_hidpp_event().
> This is IMO a design flaw and it should be fixed in a better way.
> 
> I'd better have:
> 
> - A check on the report size
> - A call to the specific hidpp_raw_hidpp_event()
> - if the previous does not return 1 (consumed event), then check on
> all subclasses and call their specific raw_event.
> 
> Does that make sense?
> 
> If you agree, you can split the patch in 3, one for the -dj, one for
> the -hidpp checks, and one for the redesign. I'd be happy to make the
> redesign if you do not want to reshuffle it in a third patch.

wtp_raw_event got called earlier through the long HID++ report handler
(which returns, so it cannot be called twice?). It looked surprising at
first, so it makes sense to split it up. I'll send a V2 for this patch
(leaving the other ones in this bundle untouched).

Kind regards,
Peter

PS. I saw a mail on LKML from a maintainer who was not so happy with the
timing of patches. If my patch submissions are at the wrong moment,
please let me know.

>
> Cheers,
> Benjamin
> 
> > -
> >         return 0;
> >  }
> >
> > --
> > 2.1.3


  reply	other threads:[~2014-12-16 15:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16  0:50 [PATCH 0/3] HID: logitech-{dj,hidpp}: more reliability fixes Peter Wu
2014-12-16  0:50 ` [PATCH 1/3] HID: logitech-hidpp: detect HID++ 2.0 errors too Peter Wu
2014-12-16 14:33   ` Benjamin Tissoires
2014-12-16 14:52     ` Peter Wu
2014-12-18 17:26     ` Peter Wu
2014-12-18 17:57       ` Benjamin Tissoires
2014-12-17 15:30   ` Benjamin Tissoires
2014-12-19 10:03     ` Jiri Kosina
2014-12-19 10:44   ` Jiri Kosina
2014-12-16  0:50 ` [PATCH 2/3] HID: logitech-{dj,hidpp}: check report length Peter Wu
2014-12-16 14:53   ` Benjamin Tissoires
2014-12-16 15:20     ` Peter Wu [this message]
2014-12-16 15:38       ` Benjamin Tissoires
2014-12-16 15:55         ` [PATCH v2 1/3] HID: logitech-dj: " Peter Wu
2014-12-16 15:55           ` [PATCH v2 2/3] HID: logitech-hidpp: check WTP " Peter Wu
2014-12-16 21:56             ` Benjamin Tissoires
2014-12-17  7:53             ` Jiri Kosina
2014-12-16 15:55           ` [PATCH v2 3/3] HID: logitech-hidpp: separate HID++ from WTP processing Peter Wu
2014-12-16 22:00             ` Benjamin Tissoires
2014-12-16 23:23               ` [PATCH " Peter Wu
2014-12-17  7:55                 ` Jiri Kosina
2014-12-16 21:55           ` [PATCH v2 1/3] HID: logitech-dj: check report length Benjamin Tissoires
2014-12-17  7:53           ` Jiri Kosina
2014-12-19 10:48         ` [PATCH 2/3] HID: logitech-{dj,hidpp}: " Jiri Kosina
2014-12-16  0:50 ` [PATCH 3/3] HID: logitech-hidpp: avoid unintended fall-through Peter Wu
2014-12-16 14:54   ` Benjamin Tissoires
2014-12-17 15:32     ` Benjamin Tissoires
2014-12-19 10:45   ` Jiri Kosina

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=9001812.kk9brShn75@al \
    --to=peter@lekensteyn.nl \
    --cc=benjamin.tissoires@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nlopezcasad@logitech.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).