linux-stable.git/drivers/hid, branch v4.1.45

HID: ignore Petzl USB headlamp

2017-09-10T20:35:58+00:00

[ Upstream commit 08f9572671c8047e7234cbf150869aa3c3d59a97 ]

This headlamp contains a dummy HID descriptor which pretends to be
a mouse-like device, but can't be used as a mouse at all.

Reported-by: Lukas Ocilka 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: core: prevent out-of-bound readings

2017-08-05T23:52:07+00:00

[ Upstream commit 50220dead1650609206efe91f0cc116132d59b3f ]

Plugging a Logitech DJ receiver with KASAN activated raises a bunch of
out-of-bound readings.

The fields are allocated up to MAX_USAGE, meaning that potentially, we do
not have enough fields to fit the incoming values.
Add checks and silence KASAN.

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: i2c-hid: Add sleep between POWER ON and RESET

2017-07-31T17:37:51+00:00

[ Upstream commit a89af4abdf9b353cdd6f61afc0eaaac403304873 ]

Support for the Asus Touchpad was recently added. It turns out this
device can fail initialisation (and become unusable) when the RESET
command is sent too soon after the POWER ON command.

Unfortunately the i2c-hid specification does not specify the need for
a delay between these two commands. But it was discovered the Windows
driver has a 1ms delay.

As a result, this patch modifies the i2c-hid module to add a sleep
inbetween the POWER ON and RESET commands which lasts between 1ms and 5ms.

See https://github.com/vlasenko/hid-asus-dkms/issues/24 for further
details.

Signed-off-by: Brendan McGrath 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: hid-cypress: validate length of report

2017-03-06T22:29:11+00:00

[ Upstream commit 1ebb71143758f45dc0fa76e2f48429e13b16d110 ]

Make sure we have enough of a report structure to validate before
looking at it.

Reported-by: Benoit Camredon 
Tested-by: Benoit Camredon 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: uhid: fix timeout when probe races with IO

2016-08-14T21:22:42+00:00

[ Upstream commit 67f8ecc550b5bda03335f845dc869b8501d25fd0 ]

Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination
with uhid. If any of these stacks is used with a HID device for which the driver
performs a HID request as part .probe (or technically another HID operation),
this results in a deadlock situation. The deadlock results in a 5 second timeout
for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations
have a chance of succeeding.

The root cause for the problem is that uhid only allows for one request to be
processed at a time per uhid instance and locks out other operations. This means
that if a user space is creating a new HID device through 'UHID_CREATE', which
ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a
read for calibration data would trigger a HID operation on uhid again, but it
won't go out to userspace, because it is still stuck in UHID_CREATE.
In addition bluetooth stacks are typically single threaded, so they wouldn't be
able to handle any requests while waiting on uhid.

Lucikly the UHID spec is somewhat flexible and allows for fixing the issue,
without breaking user space. The idea which the patch implements as discussed
with David Herrmann is to decouple adding of a hid device (which triggers .probe)
from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or
else will wait a tiny bit of time in .probe for a lock). A HID driver has to call
HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which
triggers UHID_START to user space. Any HID operations should function now within
.probe and won't deadlock because userspace is stuck on UHID_CREATE.

We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with
BlueZ stacks. Prior to the patch they had the deadlock issue.

[jkosina@suse.cz: reword subject]
Signed-off-by: Roderick Colenbrander 
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina 

Signed-off-by: Sasha Levin

HID: logitech: fix Dual Action gamepad support

2016-07-11T03:06:55+00:00

[ Upstream commit 5d74325a2201376a95520a4a38a1ce2c65761c49 ]

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: Sasha Levin

HID: hiddev: validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commands

2016-07-11T00:20:04+00:00

[ Upstream commit 93a2001bdfd5376c3dc2158653034c20392d15c5 ]

This patch validates the num_values parameter from userland during the
HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set
to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter
leading to a heap overflow.

Cc: stable@vger.kernel.org
Signed-off-by: Scott Bauer 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: elo: kill not flush the work

2016-07-11T00:19:52+00:00

[ Upstream commit ed596a4a88bd161f868ccba078557ee7ede8a6ef ]

Flushing a work that reschedules itself is not a sensible operation. It needs
to be killed. Failure to do so leads to a kernel panic in the timer code.

CC: stable@vger.kernel.org
Signed-off-by: Oliver Neukum 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: usbhid: fix inconsistent reset/resume/reset-resume behavior

2016-04-19T14:14:04+00:00

[ Upstream commit 972e6a993f278b416a8ee3ec65475724fc36feb2 ]

The usbhid driver has inconsistently duplicated code in its post-reset,
resume, and reset-resume pathways.

	reset-resume doesn't check HID_STARTED before trying to
	restart the I/O queues.

	resume fails to clear the HID_SUSPENDED flag if HID_STARTED
	isn't set.

	resume calls usbhid_restart_queues() with usbhid->lock held
	and the others call it without holding the lock.

The first item in particular causes a problem following a reset-resume
if the driver hasn't started up its I/O.  URB submission fails because
usbhid->urbin is NULL, and this triggers an unending reset-retry loop.

This patch fixes the problem by creating a new subroutine,
hid_restart_io(), to carry out all the common activities.  It also
adds some checks that were missing in the original code:

	After a reset, there's no need to clear any halted endpoints.

	After a resume, if a reset is pending there's no need to
	restart any I/O until the reset is finished.

	After a resume, if the interrupt-IN endpoint is halted there's
	no need to submit the input URB until the halt has been
	cleared.

Signed-off-by: Alan Stern 
Reported-by: Daniel Fraga 
Tested-by: Daniel Fraga 
CC: 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

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

2016-04-18T12:50:58+00:00

[ Upstream commit 3b654288b196ceaa156029d9457ccbded0489b98 ]

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.

Cc: stable@vger.kernel.org
Reported-by: Alexander Potapenko 
Signed-off-by: Dmitry Torokhov 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin