linux-stable.git/drivers/input, branch v4.1.23

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

2016-04-18T12:51:08+00:00

[ Upstream commit 950336ba3e4a1ffd2ca60d29f6ef386dd2c7351d ]

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

Input: synaptics - handle spurious release of trackstick buttons, again

2016-04-18T12:51:02+00:00

[ Upstream commit 82be788c96ed5978d3cb4a00079e26b981a3df3f ]

Looks like the fimware 8.2 still has the extra buttons spurious release
bug.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=114321
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin

Input: ims-pcu - sanity check against missing interfaces

2016-04-18T12:51:01+00:00

[ Upstream commit a0ad220c96692eda76b2e3fd7279f3dcd1d8a8ff ]

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

Input: powermate - fix oops with malicious USB descriptors

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

[ Upstream commit 9c6ba456711687b794dcf285856fc14e2c76074f ]

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

Input: vmmouse - fix absolute device registration

2016-02-23T05:49:36+00:00

[ Upstream commit d4f1b06d685d11ebdaccf11c0db1cb3c78736862 ]

We should set device's capabilities first, and then register it,
otherwise various handlers already present in the kernel will not be
able to connect to the device.

Reported-by: Lauri Kasanen 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin

Input: elantech - mark protocols v2 and v3 as semi-mt

2016-02-03T19:01:46+00:00

[ Upstream commit 6544a1df11c48c8413071aac3316792e4678fbfb ]

When using a protocol v2 or v3 hardware, elantech uses the function
elantech_report_semi_mt_data() to report data. This devices are rather
creepy because if num_finger is 3, (x2,y2) is (0,0). Yes, only one valid
touch is reported.

Anyway, userspace (libinput) is now confused by these (0,0) touches,
and detect them as palm, and rejects them.

Commit 3c0213d17a09 ("Input: elantech - fix semi-mt protocol for v3 HW")
was sufficient enough for xf86-input-synaptics and libinput before it has
palm rejection. Now we need to actually tell libinput that this device is
a semi-mt one and it should not rely on the actual values of the 2 touches.

Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin

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

2016-02-01T19:54:05+00:00

[ Upstream commit dd0d0d4de582a6a61c032332c91f4f4cb2bab569 ]

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 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin

Input: alps - only the Dell Latitude D420/430/620/630 have separate stick button bits

2015-11-09T22:33:38+00:00

commit 195562194aad3a0a3915941077f283bcc6347b9b upstream.

commit 92bac83dd79e ("Input: alps - non interleaved V2 dualpoint has
separate stick button bits") assumes that all alps v2 non-interleaved
dual point setups have the separate stick button bits.

Later we limited this to Dell laptops only because of reports that this
broke things on non Dell laptops. Now it turns out that this breaks things
on the Dell Latitude D600 too. So it seems that only the Dell Latitude
D420/430/620/630, which all share the same touchpad / stick combo,
have these separate bits.

This patch limits the checking of the separate bits to only these models
fixing regressions with other models.

Reported-and-tested-by: Larry Finger 
Tested-by: Hans de Goede 
Signed-off-by: Hans de Goede 
Acked-By: Pali Rohár 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: evdev - do not report errors form flush()

2015-09-29T17:26:01+00:00

commit eb38f3a4f6e86f8bb10a3217ebd85ecc5d763aae upstream.

We've got bug reports showing the old systemd-logind (at least
system-210) aborting unexpectedly, and this turned out to be because
of an invalid error code from close() call to evdev devices.  close()
is supposed to return only either EINTR or EBADFD, while the device
returned ENODEV.  logind was overreacting to it and decided to kill
itself when an unexpected error code was received.  What a tragedy.

The bad error code comes from flush fops, and actually evdev_flush()
returns ENODEV when device is disconnected or client's access to it is
revoked. But in these cases the fact that flush did not actually happen is
not an error, but rather normal behavior. For non-disconnected devices
result of flush is also not that interesting as there is no potential of
data loss and even if it fails application has no way of handling the
error. Because of that we are better off always returning success from
evdev_flush().

Also returning EINTR from flush()/close() is discouraged (as it is not
clear how application should handle this error), so let's stop taking
evdev->mutex interruptibly.

Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=939834
Signed-off-by: Takashi Iwai 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: gpio_keys_polled - request GPIO pin as input.

2015-09-13T16:07:49+00:00

commit 1ae5ddb6f8837558928a1a694c7b8af7f09fdd21 upstream.

GPIOF_IN flag was lost in:
Commit 633a21d80b4a("input: gpio_keys_polled: Add support for GPIO
descriptors").

Without this flag, legacy code path (for non-descriptor GPIO declarations)
would configure GPIO as output (0 meaning GPIOF_DIR_OUT | GPIOF_INIT_LOW).

Signed-off-by: Vincent Pelletier 
Reviewed-by: Mika Westerberg 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman