lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1414884310-19842-2-git-send-email-pali.rohar@gmail.com>
Date:	Sun,  2 Nov 2014 00:25:07 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Hans de Goede <hdegoede@...hat.com>,
	Yunkang Tang <yunkang.tang@...alps.com>,
	Tommy Will <tommywill2011@...il.com>
Cc:	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Pali Rohár <pali.rohar@...il.com>
Subject: [PATCH v3 1/4] input: alps: Do not try to parse data as 3 bytes packet when driver is out of sync

5th and 6th byte of ALPS trackstick V3 protocol match condition for first byte
of PS/2 3 bytes packet. When driver enters out of sync state and ALPS trackstick
is sending data then driver match 5th, 6th and next 1st bytes as PS/2.

It basically means if user is using trackstick when driver is in out of sync
state driver will never resync. Processing these bytes as 3 bytes PS/2 data
cause total mess (random cursor movements, random clicks) and make trackstick
unusable until psmouse driver decide to do full device reset.

Lot of users reported problems with ALPS devices on Dell Latitude E6440, E6540
and E7440 laptops. ALPS device or Dell EC for unknown reason send some invalid
ALPS PS/2 bytes which cause driver out of sync. It looks like that i8042 and
psmouse/alps driver always receive group of 6 bytes packets so there are no
missing bytes and no bytes were inserted between valid once.

This patch does not fix root of problem with ALPS devices found in Dell Latitude
laptops but it does not allow to process some (invalid) subsequence of 6 bytes
ALPS packets as 3 bytes PS/2 when driver is out of sync.

So with this patch trackstick input device does not report bogus data when
also driver is out of sync, so trackstick should be usable on those machines.

Unknown is also information which ALPS devices send 3 bytes packets and why
ALPS driver needs to handle also bare PS/2 packets. According to git (and plus
historic tree from bitkeeper) code for processing 3 bytes bare PS/2 packets
is there since first version of alps.c existence (since 2.6.9-rc2).

We do not want to break some older ALPS devices. And disabling processing bare
PS/2 packets when driver is out of sync should not break it.

Signed-off-by: Pali Rohár <pali.rohar@...il.com>
Tested-by: Pali Rohár <pali.rohar@...il.com>
Cc: stable@...r.kernel.org
---
 drivers/input/mouse/alps.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 2b0ae8c..a772745 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -1156,7 +1156,9 @@ static psmouse_ret_t alps_process_byte(struct psmouse *psmouse)
 {
 	struct alps_data *priv = psmouse->private;
 
-	if ((psmouse->packet[0] & 0xc8) == 0x08) { /* PS/2 packet */
+	/* FIXME: Could we receive bare PS/2 packets from DualPoint devices?? */
+	if (!psmouse->out_of_sync_cnt &&
+	    (psmouse->packet[0] & 0xc8) == 0x08) { /* PS/2 packet */
 		if (psmouse->pktcnt == 3) {
 			alps_report_bare_ps2_packet(psmouse, psmouse->packet,
 						    true);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ