linux.git/drivers/input, branch v3.10.103

Input: xpad - validate USB endpoint count during probe

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

commit caca925fca4fb30c67be88cacbe908eec6721e43 upstream.

This prevents a malicious USB device from causing an oops.

Signed-off-by: Cameron Gutman 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

Input: wacom_w8001 - w8001_MAX_LENGTH should be 13

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

commit 12afb34400eb2b301f06b2aa3535497d14faee59 upstream.

Somehow the patch that added two-finger touch support forgot to update
W8001_MAX_LENGTH from 11 to 13.

Signed-off-by: Ping Cheng 
Reviewed-by: Peter Hutterer 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Willy Tarreau

Input: uinput - handle compat ioctl for UI_SET_PHYS

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

commit affa80bd97f7ca282d1faa91667b3ee9e4c590e6 upstream.

When running a 32-bit userspace on a 64-bit kernel, the UI_SET_PHYS
ioctl needs to be treated with special care, as it has the pointer
size encoded in the command.

Signed-off-by: Ricky Liang 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Willy Tarreau

Input: max8997-haptic - fix NULL pointer dereference

2016-06-07T08:42:53+00:00

commit 6ae645d5fa385f3787bf1723639cd907fe5865e7 upstream.

NULL pointer derefence happens when booting with DTB because the
platform data for haptic device is not set in supplied data from parent
MFD device.

The MFD device creates only platform data (from Device Tree) for itself,
not for haptic child.

Unable to handle kernel NULL pointer dereference at virtual address 0000009c
pgd = c0004000
	[0000009c] *pgd=00000000
	Internal error: Oops: 5 [#1] PREEMPT SMP ARM
	(max8997_haptic_probe) from [] (platform_drv_probe+0x4c/0xb0)
	(platform_drv_probe) from [] (driver_probe_device+0x214/0x2c0)
	(driver_probe_device) from [] (__driver_attach+0xac/0xb0)
	(__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
	(bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
	(bus_add_driver) from [] (driver_register+0x78/0xf8)
	(driver_register) from [] (do_one_initcall+0x90/0x1d8)
	(do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1fc)
	(kernel_init_freeable) from [] (kernel_init+0x8/0x114)
	(kernel_init) from [] (ret_from_fork+0x14/0x3c)

Signed-off-by: Marek Szyprowski 
Cc: 
Fixes: 104594b01ce7 ("Input: add driver support for MAX8997-haptic")
[k.kozlowski: Write commit message, add CC-stable]
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Willy Tarreau

Input: ads7846 - correct the value got from SPI

2016-06-07T08:42:53+00:00

commit 879f2fea8a5a748bcbf98d2cdce9139c045505d3 upstream.

According to the touch controller spec, SPI return a 16 bit value, only 12
bits are valid, they are bit[14-3].

The value of MISO and MOSI can be configured when SPI is in idle mode.
Currently this touch driver assumes the SPI bus sets the MOSI and MISO in
low level when SPI bus is in idle mode. So the bit[15] of the value got
from SPI bus is always 0. But when SPI bus congfigures the MOSI and MISO in
high level during the SPI idle mode, the bit[15] of the value get from SPI
is always 1. If bit[15] is not masked, we may get the wrong value.

Mask the invalid bit to make sure the correct value gets returned.
Regardless of the SPI bus idle configuration.

Signed-off-by: Andrey Gelman 
Signed-off-by: Haibo Chen 
Signed-off-by: Igor Grinberg 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Willy Tarreau

Input: gtco - fix crash on detecting device without endpoints

2016-06-07T08:42:51+00:00

commit 162f98dea487206d9ab79fc12ed64700667a894d upstream.

The gtco driver expects at least one valid endpoint. If given malicious
descriptors that specify 0 for the number of endpoints, it will crash in
the probe function. Ensure there is at least one endpoint on the interface
before using it.

Also let's fix a minor coding style issue.

The full correct report of this issue can be found in the public
Red Hat Bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=1283385

Reported-by: Ralf Spenneberg 
Signed-off-by: Vladis Dronov 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Willy Tarreau

Input: ati_remote2 - fix crashes on detecting device with invalid descriptor

2016-06-07T08:42:47+00:00

commit 950336ba3e4a1ffd2ca60d29f6ef386dd2c7351d upstream.

The ati_remote2 driver expects at least two interfaces with one
endpoint each. If given malicious descriptor that specify one
interface or no endpoints, it will crash in the probe function.
Ensure there is at least two interfaces and one endpoint for each
interface before using it.

The full disclosure: http://seclists.org/bugtraq/2016/Mar/90

Reported-by: Ralf Spenneberg 
Signed-off-by: Vladis Dronov 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Willy Tarreau

Input: ims-pcu - sanity check against missing interfaces

2016-06-07T08:42:47+00:00

commit a0ad220c96692eda76b2e3fd7279f3dcd1d8a8ff upstream.

A malicious device missing interface can make the driver oops.
Add sanity checking.

Signed-off-by: Oliver Neukum 
CC: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Willy Tarreau

Input: powermate - fix oops with malicious USB descriptors

2016-06-07T08:42:46+00:00

commit 9c6ba456711687b794dcf285856fc14e2c76074f upstream.

The powermate driver expects at least one valid USB endpoint in its
probe function.  If given malicious descriptors that specify 0 for
the number of endpoints, it will crash.  Validate the number of
endpoints on the interface before using them.

The full report for this issue can be found here:
http://seclists.org/bugtraq/2016/Mar/85

Reported-by: Ralf Spenneberg 
Cc: stable 
Signed-off-by: Josh Boyer 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Willy Tarreau

Input: i8042 - add Fujitsu Lifebook U745 to the nomux list

2016-02-25T19:57:49+00:00

commit dd0d0d4de582a6a61c032332c91f4f4cb2bab569 upstream.

Without i8042.nomux=1 the Elantech touch pad is not working at all on
a Fujitsu Lifebook U745. This patch does not seem necessary for all
U745 (maybe because of different BIOS versions?). However, it was
verified that the patch does not break those (see opensuse bug 883192:
https://bugzilla.opensuse.org/show_bug.cgi?id=883192).

Signed-off-by: Aurélien Francillon 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman