On Wed, 27 Aug 2014, Bruno Prémont wrote:
> > The report passed to us from transport driver could potentially be
> > arbitrarily large, therefore we better sanity-check it so that raw_data
> > that we hold in picolcd_pending structure are always kept within proper
> > bounds.
> >
> > Cc: sta...@vger.kernel.org
> > Reported-by: Steven Vittitoe <scvi...@google.com>
> > Signed-off-by: Jiri Kosina <jkos...@suse.cz>
>
> Acked-by: Bruno Prémont <bonb...@linux-vserver.org>
Thanks.
> > ---
> > drivers/hid/hid-picolcd_core.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
> > index acbb0210..020df3c 100644
> > --- a/drivers/hid/hid-picolcd_core.c
> > +++ b/drivers/hid/hid-picolcd_core.c
> > @@ -350,6 +350,12 @@ static int picolcd_raw_event(struct hid_device *hdev,
> > if (!data)
> > return 1;
> >
> > + if (size > 64) {
> > + hid_warn(hdev, "invalid size value (%d) for picolcd raw
> > event\n",
> > + size);
>
> Is it worth adding report->id to this hid_warn()?
>
> A valid device is not expected to ever send >64 bytes reports but in
> case a firmware update would do so it would help to know for which
> report it was.
It definitely wouldn't hurt. Pull request with the original patch is now
on its way to Linus though, so let's do this as a followup patch on top
once this is merged.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
