linux-kernel - Re: [PATCH] Input: elantench - Fix the firmware misreport coordinates for trackpoint occasionally.

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: <3a98b10e-6b78-b769-e22d-2496d7bcd69d@cs.unc.edu>
Date:   Sun, 7 Nov 2021 15:02:27 -0500
From:   Yufei Du <yufeidu@...unc.edu>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
        jingle.wu@....com.tw, josh.chen@....com.tw, dave.wang@....com.tw,
        phoenix <phoenix@....com.tw>
Subject: Re: [PATCH] Input: elantench - Fix the firmware misreport coordinates
 for trackpoint occasionally.

Hi Dmitry,

I am a user currently suffering from the firmware bug that causes my trackpoint 
to be unusable on my Lenovo X13 Gen 1 AMD. I tested this patch in the latest 
5.15 mainline kernel tree and can possibly answer your questions regarding the 
patch.

 > I think this will reject X coordinates in range [0, 127]. Is this really
 > what is needed?

As Phoenix explained in his reply, the patch will reject X and Y coordinates 
larger than 127 or smaller than -127. This is because the most significant bit 
of packet[1] (for X) and packet[2] (for Y) are inverse of the sign bit. Although 
I do not have the formal design specification of the device, I tried pushing the 
trackpoint as hard as I could, and the X and Y coordinates never go beyond 
+/-127 normally, so I believe that this patch would not cause any functionality 
issue.

 > What kind of patterns are you observing when firmware
 > misreports coordinates?

Here is a sample log I observed (with elantech.debug set to 2 for more debugging 
messages):
psmouse serio1: elantech: PS/2 packet [10 00 80 26 f9 0a]
psmouse serio1: elantech: PS/2 packet [10 00 80 26 00 80]
psmouse serio1: elantech: PS/2 packet [10 00 80 00 00 00]
psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
psmouse serio1: elantech: PS/2 packet [10 00 80 26 f8 0b]
psmouse serio1: Touchpad at isa0060/serio1/input0 - driver resynced.

The first packet is a valid packet. The second packet is the incorrect packet 
that this patch prevents. The third packet is a corrupted packet that psmouse 
detects (as shown in the "lost sync" message), and the fourth packet is a valid 
packet again. Without the patch, the second packet would cause the cursor to 
jump to the edge of the screen.

So far, all my logs of this issue show the same pattern of a jumpy incorrect 
packet followed by a corrupted packet that causes psmouse to lose sync. There 
are more logs and discussions in the BugZilla entry here: 
https://bugzilla.kernel.org/show_bug.cgi?id=209167

Hope my explanation helped a bit.

Thanks!

Best,
Yufei Du