linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gustavo Padovan <gustavo@padovan.org>
To: Jiri Kosina <jkosina@suse.cz>
Cc: "Bruno Prémont" <bonbons@linux-vserver.org>,
	"Adam Kropelin" <akropel1@rochester.rr.com>,
	"Grant Grundler" <grundler@parisc-linux.org>,
	linux-input@vger.kernel.org
Subject: Re: [PATCH] HID: fix data access in implement()
Date: Tue, 9 Jul 2013 19:59:44 +0100	[thread overview]
Message-ID: <20130709185944.GA14591@joana> (raw)
In-Reply-To: <alpine.LNX.2.00.1307092042190.26857@pobox.suse.cz>

Hi Jiri,

* Jiri Kosina <jkosina@suse.cz> [2013-07-09 20:44:27 +0200]:

> implement() is setting bytes in LE data stream. In case the data
> is not aligned to 64bits, it reads past the allocated buffer. It
> doesn't really change any value there (it's properly bitmasked), but
> in case that this read past the boundary hits a page boundary, pagefault
> happens when accessing 64bits of 'x' in implement(), and kernel oopses.
> 
> This happens much more often when numbered reports are in use, as the
> initial 8bit skip in the buffer makes the whole process work on values
> which are not aligned to 64bits.
> 
> This problem dates back to attempts in 2005 and 2006 to make implement()
> and extract() as generic as possible, and even back then the problem
> was realized by Adam Kroperlin, but falsely assumed to be impossible
> to cause any harm:
> 
>   http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
> 
> I have made several attempts at fixing it "on the spot" directly in
> implement(), but the results were horrible; the special casing for processing
> last 64bit chunk and switching to different math makes it unreadable mess.
> 
> I therefore took a path to allocate a few bytes more which will never make
> it into final report, but are there as a cushion for all the 64bit math
> operations happening in implement() and extract().
> 
> All callers of hid_output_report() are converted at the same time to allocate
> the buffer by newly introduced hid_alloc_report_buf() helper.
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
>  drivers/hid/hid-core.c            |   19 ++++++++++++++++++-
>  drivers/hid/hid-logitech-dj.c     |   12 ++++++++++--
>  drivers/hid/hid-picolcd_debugfs.c |   10 +++++++++-
>  drivers/hid/usbhid/hid-core.c     |    4 ++--
>  include/linux/hid.h               |    1 +
>  net/bluetooth/hidp/core.c         |   14 +++++++++-----
>  6 files changed, 49 insertions(+), 11 deletions(-)

For the bluetooth part:

Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

	Gustavo

  reply	other threads:[~2013-07-09 18:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-09 18:44 [PATCH] HID: fix data access in implement() Jiri Kosina
2013-07-09 18:59 ` Gustavo Padovan [this message]
2013-07-10 12:11 ` Bruno Prémont
2013-07-10 14:12 ` Benjamin Tissoires
2013-07-10 17:49   ` Jiri Kosina
2013-07-10 17:56 ` [PATCH v2] " 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=20130709185944.GA14591@joana \
    --to=gustavo@padovan.org \
    --cc=akropel1@rochester.rr.com \
    --cc=bonbons@linux-vserver.org \
    --cc=grundler@parisc-linux.org \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    /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).