linux-stable.git/drivers/hid, branch v3.16.35

HID: i2c-hid: fix OOB write in i2c_hid_set_or_send_report()

2016-04-30T22:06:00+00:00

commit 3b654288b196ceaa156029d9457ccbded0489b98 upstream.

Even though hid_hw_* checks that passed in data_len is less than
HID_MAX_BUFFER_SIZE it is not enough, as i2c-hid does not necessarily
allocate buffers of HID_MAX_BUFFER_SIZE but rather checks all device
reports and select largest size. In-kernel users normally just send as much
data as report needs, so there is no problem, but hidraw users can do
whatever they please:

BUG: KASAN: slab-out-of-bounds in memcpy+0x34/0x54 at addr ffffffc07135ea80
Write of size 4101 by task syz-executor/8747
CPU: 2 PID: 8747 Comm: syz-executor Tainted: G    BU         3.18.0 #37
Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
Call trace:
[] dump_backtrace+0x0/0x258 arch/arm64/kernel/traps.c:83
[] show_stack+0x1c/0x2c arch/arm64/kernel/traps.c:172
[<     inline     >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x90/0x140 lib/dump_stack.c:50
[<     inline     >] print_error_description mm/kasan/report.c:97
[<     inline     >] kasan_report_error mm/kasan/report.c:278
[] kasan_report+0x268/0x530 mm/kasan/report.c:305
[] __asan_storeN+0x20/0x150 mm/kasan/kasan.c:718
[] memcpy+0x30/0x54 mm/kasan/kasan.c:299
[] __i2c_hid_command+0x2b0/0x7b4 drivers/hid/i2c-hid/i2c-hid.c:178
[<     inline     >] i2c_hid_set_or_send_report drivers/hid/i2c-hid/i2c-hid.c:321
[] i2c_hid_output_raw_report.isra.2+0x3d4/0x4b8 drivers/hid/i2c-hid/i2c-hid.c:589
[] i2c_hid_output_report+0x54/0x68 drivers/hid/i2c-hid/i2c-hid.c:602
[<     inline     >] hid_hw_output_report include/linux/hid.h:1039
[] hidraw_send_report+0x400/0x414 drivers/hid/hidraw.c:154
[] hidraw_write+0x40/0x64 drivers/hid/hidraw.c:177
[] vfs_write+0x1d4/0x3cc fs/read_write.c:534
[<     inline     >] SYSC_pwrite64 fs/read_write.c:627
[] SyS_pwrite64+0xec/0x144 fs/read_write.c:614
Object at ffffffc07135ea80, in cache kmalloc-512
Object allocated with size 268 bytes.

Let's check data length against the buffer size before attempting to copy
data over.

Reported-by: Alexander Potapenko 
Signed-off-by: Dmitry Torokhov 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Ben Hutchings

HID: fix hid_ignore_special_drivers module parameter

2016-04-30T22:05:48+00:00

commit 4392bf333388cabdad5afe5b1500002d7b9c318e upstream.

hid_ignore_special_drivers works fine until hid_scan_report autodetects and
reassign devices (for hid-multitouch, hid-microsoft and hid-rmi).

Simplify the handling of the parameter: if it is there, use hid-generic, no
matter what, and if not, scan the device or rely on the hid_have_special_driver
table.

This was detected while trying to disable hid-multitouch on a Surface Pro cover
which prevented to use the keyboard.

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Ben Hutchings

HID: core: do not scan reports if the group is already set

2016-04-30T22:05:48+00:00

commit 9578f41aeaee5010384f4f8484da1566e2ce4901 upstream.

This allows the transport layer (I have in mind hid-logitech-dj and uhid)
to set the group before it is added to the hid bus. This way, it can
bypass the hid_scan_report() call, and choose in advance which driver
will handle the newly created hid device.

Signed-off-by: Benjamin Tisssoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Ben Hutchings

HID: logitech: fix Dual Action gamepad support

2016-04-30T22:05:47+00:00

commit 5d74325a2201376a95520a4a38a1ce2c65761c49 upstream.

The patch that added Logitech Dual Action gamepad support forgot to
update the special driver list for the device. This caused the logitech
driver not to probe unless kernel module load order was favorable.
Update the special driver list to fix it. Thanks to Simon Wood for the
idea.

Cc: Vitaly Katraew 
Fixes: 56d0c8b7c8fb ("HID: add support for Logitech Dual Action gamepads")
Signed-off-by: Grazvydas Ignotas 
Signed-off-by: Jiri Kosina 
Signed-off-by: Ben Hutchings

HID: usbhid: fix recursive deadlock

2016-02-03T10:27:53+00:00

commit e470127e9606b1fa151c4184243e61296d1e0c0f upstream.

The critical section protected by usbhid->lock in hid_ctrl() is too
big and because of this it causes a recursive deadlock. "Too big" means
the case statement and the call to hid_input_report() do not need to be
protected by the spinlock (no URB operations are done inside them).

The deadlock happens because in certain rare cases drivers try to grab
the lock while handling the ctrl irq which grabs the lock before them
as described above. For example newer wacom tablets like 056a:033c try
to reschedule proximity reads from wacom_intuos_schedule_prox_event()
calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()
which tries to grab the usbhid lock already held by hid_ctrl().

There are two ways to get out of this deadlock:
    1. Make the drivers work "around" the ctrl critical region, in the
    wacom case for ex. by delaying the scheduling of the proximity read
    request itself to a workqueue.
    2. Shrink the critical region so the usbhid lock protects only the
    instructions which modify usbhid state, calling hid_input_report()
    with the spinlock unlocked, allowing the device driver to grab the
    lock first, finish and then grab the lock afterwards in hid_ctrl().

This patch implements the 2nd solution.

Signed-off-by: Ioan-Adrian Ratiu 
Signed-off-by: Jiri Kosina 
Cc: Jason Gerecke 
Signed-off-by: Luis Henriques

HID: core: Avoid uninitialized buffer access

2015-12-09T11:40:57+00:00

commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream.

hid_connect adds various strings to the buffer but they're all
conditional. You can find circumstances where nothing would be written
to it but the kernel will still print the supposedly empty buffer with
printk. This leads to corruption on the console/in the logs.

Ensure buf is initialized to an empty string.

Signed-off-by: Richard Purdie 
[dvhart: Initialize string to "" rather than assign buf[0] = NULL;]
Cc: Jiri Kosina 
Cc: linux-input@vger.kernel.org
Signed-off-by: Darren Hart 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques

HID: usbhid: Fix the check for HID_RESET_PENDING in hid_io_error

2015-09-28T09:21:45+00:00

commit 3af4e5a95184d6d3c1c6a065f163faa174a96a1d upstream.

It was reported that after 10-20 reboots, a usb keyboard plugged
into a docking station would not work unless it was replugged in.

Using usbmon, it turns out the interrupt URBs were streaming with
callback errors of -71 for some reason.  The hid-core.c::hid_io_error was
supposed to retry and then reset, but the reset wasn't really happening.

The check for HID_NO_BANDWIDTH was inverted.  Fix was simple.

Tested by reporter and locally by me by unplugging a keyboard halfway until I
could recreate a stream of errors but no disconnect.

Signed-off-by: Don Zickus 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques

HID: cp2112: fix byte order in SMBUS operations

2015-09-28T09:21:31+00:00

commit 29e2d6d1f6f61ba2b5cc9d9867e01d8c31a6c4f7 upstream.

Change all occurrences of be16 to le16 in cp2112_xfer(),
because SMBUS words are little endian, not big endian.

Signed-off-by: Ellen Wang 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques

HID: cp2112: fix I2C_SMBUS_BYTE write

2015-09-28T09:21:30+00:00

commit 6d00d153f00097d259f86304e11858a50a1b8ad1 upstream.

When doing an I2C_SMBUS_BYTE write (one byte write, no address),
the data to be written is in "command" not "data->byte".

Signed-off-by: Ellen Wang 
Acked-by: Wolfram Sang 
Reviewed-by: Antonio Borneo 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques

HID: usbhid: add Chicony/Pixart usb optical mouse that needs QUIRK_ALWAYS_POLL

2015-08-27T14:01:11+00:00

commit 7250dc3fee806eb2b7560ab7d6072302e7ae8cf8 upstream.

I received a report from an user of following mouse which needs this quirk:

usb 1-1.6: USB disconnect, device number 58
usb 1-1.6: new low speed USB device number 59 using ehci_hcd
usb 1-1.6: New USB device found, idVendor=04f2, idProduct=1053
usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.6: Product: USB Optical Mouse
usb 1-1.6: Manufacturer: PixArt
usb 1-1.6: configuration #1 chosen from 1 choice
input: PixArt USB Optical Mouse as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input5887
generic-usb 0003:04F2:1053.16FE: input,hidraw2: USB HID v1.11 Mouse [PixArt USB Optical Mouse] on usb-0000:00:1a.0-1.6/input0

The quirk was tested by the reporter and it fixed the frequent disconnections etc.

[jkosina@suse.cz: reorder the position in hid-ids.h]
Signed-off-by: Herton R. Krzesinski 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Luis Henriques