linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Gustavo Padovan <gustavo@padovan.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: Wed, 10 Jul 2013 14:11:07 +0200	[thread overview]
Message-ID: <20130710141107.14bb5fe1@neptune.home> (raw)
In-Reply-To: <alpine.LNX.2.00.1307092042190.26857@pobox.suse.cz>

Hi Jiri,

Some notes regarding picoLCD part below.

On Tue, 09 July 2013 Jiri Kosina <jkosina@suse.cz> wrote:
> 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(-)
> 
> diff --git a/drivers/hid/hid-picolcd_debugfs.c b/drivers/hid/hid-picolcd_debugfs.c
> index 59ab8e1..784a17c 100644
> --- a/drivers/hid/hid-picolcd_debugfs.c
> +++ b/drivers/hid/hid-picolcd_debugfs.c
> @@ -394,7 +394,7 @@ static void dump_buff_as_hex(char *dst, size_t dst_sz, const u8 *data,
>  void picolcd_debug_out_report(struct picolcd_data *data,
>  		struct hid_device *hdev, struct hid_report *report)
>  {
> -	u8 raw_data[70];
> +	u8 *raw_data;
>  	int raw_size = (report->size >> 3) + 1;
>  	char *buff;
>  #define BUFF_SZ 256
> @@ -407,11 +407,18 @@ void picolcd_debug_out_report(struct picolcd_data *data,
>  	if (!buff)
>  		return;
>  
> +	raw_data = hid_alloc_report_buf(report, GFP_ATOMIC);
> +	if (!raw_data) {
> +		kfree(buff);
> +		return;
> +	}
> +
>  	snprintf(buff, BUFF_SZ, "\nout report %d (size %d) =  ",
>  			report->id, raw_size);
>  	hid_debug_event(hdev, buff);
>  	if (raw_size + 5 > sizeof(raw_data)) {

As you change raw_data from u8[] to u8* the sizeof(raw_data)
will not do the right thing.
In addition the whole test (if it were correct) is not needed anymore as
hid_alloc_report_buf() should always return a buffer of sufficient size.


So just drop the test:

-	if (raw_size + 5 > sizeof(raw_data)) {
-		kfree(buff);
-		hid_debug_event(hdev, " TOO BIG\n");
-		return;
-	} else {
-		raw_data[0] = report->id;
-		hid_output_report(report, raw_data);
-		dump_buff_as_hex(buff, BUFF_SZ, raw_data, raw_size);
-		hid_debug_event(hdev, buff);
-        }
+	raw_data[0] = report->id;
+	hid_output_report(report, raw_data);
+	dump_buff_as_hex(buff, BUFF_SZ, raw_data, raw_size);
+	hid_debug_event(hdev, buff);

>  		kfree(buff);
> +		kfree(raw_data);
>  		hid_debug_event(hdev, " TOO BIG\n");
>  		return;
>  	} else {
> @@ -644,6 +651,7 @@ void picolcd_debug_out_report(struct picolcd_data *data,
>  		break;
>  	}
>  	wake_up_interruptible(&hdev->debug_wait);
> +	kfree(raw_data);
>  	kfree(buff);
>  }
>  

Bruno

  parent reply	other threads:[~2013-07-10 12:19 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
2013-07-10 12:11 ` Bruno Prémont [this message]
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=20130710141107.14bb5fe1@neptune.home \
    --to=bonbons@linux-vserver.org \
    --cc=akropel1@rochester.rr.com \
    --cc=grundler@parisc-linux.org \
    --cc=gustavo@padovan.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).