linux-stable.git/drivers/hid, branch linux-3.11.y

HID: wiimote: add LEGO-wiimote VID

2013-11-13T03:08:07+00:00

commit 86b84167d4e67372376a57ea9955c5d53dae232f upstream.

The LEGO-wiimote uses a different VID than the Nintendo ID. The device is
technically the same so add the ID.

Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: uhid: allocate static minor

2013-10-14T01:14:32+00:00

commit 19872d20c890073c5207d9e02bb8f14d451a11eb upstream.

udev has this nice feature of creating "dead" /dev/ device-nodes if
it finds a devnode: modalias. Once the node is accessed, the kernel
automatically loads the module that provides the node. However, this
requires udev to know the major:minor code to use for the node. This
feature was introduced by:

  commit 578454ff7eab61d13a26b568f99a89a2c9edc881
  Author: Kay Sievers 
  Date:   Thu May 20 18:07:20 2010 +0200

      driver core: add devname module aliases to allow module on-demand auto-loading

However, uhid uses dynamic minor numbers so this doesn't actually work. We
need to load uhid to know which minor it's going to use.

Hence, allocate a static minor (just like uinput does) and we're good
to go.

Reported-by: Tom Gundersen 
Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: uhid: add devname module alias

2013-10-14T01:14:32+00:00

commit 60cbd53e4bf623fe978e6f23a6da642e730fde3a upstream.

For simple device node creation, add the devname module alias.

Signed-off-by: Marcel Holtmann 
Reviewed-by: David Herrmann 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: add Holtek USB ID 04d9:a081 SHARKOON DarkGlider

2013-10-14T01:14:32+00:00

commit 7da7cbbbeb60e0939fecdf9723b388136c175e5c upstream.

Added id, bindings and comments for Holtek USB ID 04d9:a081 SHARKOON
DarkGlider Gaming mouse to use the same corrections of the report
descriptor as Holtek 04d9:a04a. As the mouse exceed HID_MAX_USAGES
at the same offsets in the reported descriptor.
Tested on the hardware.

Signed-off-by: Anders F. U. Kiær 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: roccat: add support for KonePureOptical v2

2013-10-14T01:14:32+00:00

commit a4be0ed39f2b1ea990804ea54e39bc42d17ed5a5 upstream.

KonePureOptical is a KonePure with different sensor.

Signed-off-by: Stefan Achatz 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: wiimote: fix FF deadlock

2013-10-14T01:14:31+00:00

commit f50f9aabf32db7414551ffdfdccc71be5f3d6e7d upstream.

The input core has an internal spinlock that is acquired during event
injection via input_event() and friends but also held during FF callbacks.
That means, there is no way to share a lock between event-injection and FF
handling. Unfortunately, this is what is required for wiimote state
tracking and what we do with state.lock and input->lock.

This deadlock can be triggered when using continuous data reporting and FF
on a wiimote device at the same time. I takes me at least 30m of
stress-testing to trigger it but users reported considerably shorter
times (http://bpaste.net/show/132504/) when using some gaming-console
emulators.

The real problem is that we have two copies of internal state, one in the
wiimote objects and the other in the input device. As the input-lock is
not supposed to be accessed from outside of input-core, we have no other
chance than offloading FF handling into a worker. This actually works
pretty nice and also allows to implictly merge fast rumble changes into a
single request.

Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF
responsiveness. Initial tests were fine so lets fix the race first and if
it turns out to be too slow we can always handle FF out-of-band and skip
the queue-worker.

Reported-by: Thomas Schneider
Signed-off-by: David Herrmann 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: fix data access in implement()

2013-10-14T01:14:23+00:00

commit 27ce405039bfe6d3f4143415c638f56a3df77dca upstream.

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.

Bruno noticed that the whole raw_size test can be dropped as well, as
hid_alloc_report_buf() makes sure that the buffer is always of a proper
size.

Reviewed-by: Benjamin Tissoires 
Acked-by: Gustavo Padovan 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: logitech-dj: validate output report details

2013-10-01T16:40:59+00:00

commit 297502abb32e225fb23801fcdb0e4f6f8e17099a upstream.

A HID device could send a malicious output report that would cause the
logitech-dj HID driver to leak kernel memory contents to the device, or
trigger a NULL dereference during initialization:

[  304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b
...
[  304.780467] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
[  304.781409] IP: [] logi_dj_recv_send_report.isra.11+0x1a/0x90

CVE-2013-2895

Signed-off-by: Kees Cook 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: lenovo-tpkbd: validate output report details

2013-10-01T16:40:59+00:00

commit 0a9cd0a80ac559357c6a90d26c55270ed752aa26 upstream.

A HID device could send a malicious output report that would cause the
lenovo-tpkbd HID driver to write just beyond the output report allocation
during initialization, causing a heap overflow:

[   76.109807] usb 1-1: New USB device found, idVendor=17ef, idProduct=6009
...
[   80.462540] BUG kmalloc-192 (Tainted: G        W   ): Redzone overwritten

CVE-2013-2894

Signed-off-by: Kees Cook 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: sony: validate HID output report details

2013-10-01T16:40:59+00:00

commit 9446edb9a1740989cf6c20daf7510fb9a23be14a upstream.

This driver must validate the availability of the HID output report and
its size before it can write LED states via buzz_set_leds(). This stops
a heap overflow that is possible if a device provides a malicious HID
output report:

[  108.171280] usb 1-1: New USB device found, idVendor=054c, idProduct=0002
...
[  117.507877] BUG kmalloc-192 (Not tainted): Redzone overwritten

CVE-2013-2890

Signed-off-by: Kees Cook 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman