05 Mar, 2020
4 commits
-
commit 5c02c447eaeda29d3da121a2e17b97ccaf579b51 upstream.
Syzbot reports that "hiddev" is used after it's free in hiddev_disconnect().
The hiddev_disconnect() function sets "hiddev->exist = 0;" so
hiddev_release() can free it as soon as we drop the "existancelock"
lock. This patch moves the mutex_unlock(&hiddev->existancelock) until
after we have finished using it.Reported-by: syzbot+784ccb935f9900cc7c9e@syzkaller.appspotmail.com
Fixes: 7f77897ef2b6 ("HID: hiddev: fix potential use-after-free")
Suggested-by: Alan Stern
Signed-off-by: Dan Carpenter
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 8d2e77b39b8fecb794e19cd006a12f90b14dd077 upstream.
They are issues:
- if 'input_allocate_device()' fails and return NULL, there is no need
to free anything and 'input_free_device()' call is a no-op. It can
be axed.
- 'ret' is known to be 0 at this point, so we must set it to a
meaningful value before returningFixes: 2562756dde55 ("HID: add Alps I2C HID Touchpad-Stick support")
Signed-off-by: Christophe JAILLET
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 5ebdffd25098898aff1249ae2f7dbfddd76d8f8f upstream.
In case a report is greater than HID_MAX_BUFFER_SIZE, it is truncated,
but the report-number byte is not correctly handled. This results in a
off-by-one in the following memset, causing a kernel Oops and ensuing
system crash.Note: With commit 8ec321e96e05 ("HID: Fix slab-out-of-bounds read in
hid_field_extract") I no longer hit the kernel Oops as we instead fail
"controlled" at probe if there is a report too long in the HID
report-descriptor. hid_report_raw_event() is an exported symbol, so
presumabely we cannot always rely on this being the case.Fixes: 966922f26c7f ("HID: fix a crash in hid_report_raw_event()
function.")
Signed-off-by: Johan Korsnes
Cc: Armando Visconti
Cc: Jiri Kosina
Cc: Alan Stern
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit beae56192a2570578ae45050e73c5ff9254f63e6 upstream.
Commit 8f18eca9ebc5 ("HID: ite: Add USB id match for Acer SW5-012 keyboard
dock") added the USB id for the Acer SW5-012's keyboard dock to the
hid-ite driver to fix the rfkill driver not working.Most keyboard docks with an ITE 8595 keyboard/touchpad controller have the
"Wireless Radio Control" bits which need the special hid-ite driver on the
second USB interface (the mouse interface) and their touchpad only supports
mouse emulation, so using generic hid-input handling for anything but
the "Wireless Radio Control" bits is fine. On these devices we simply bind
to all USB interfaces.But unlike other ITE8595 using keyboard docks, the Acer Aspire Switch 10
(SW5-012)'s touchpad not only does mouse emulation it also supports
HID-multitouch and all the keys including the "Wireless Radio Control"
bits have been moved to the first USB interface (the keyboard intf).So we need hid-ite to handle the first (keyboard) USB interface and have
it NOT bind to the second (mouse) USB interface so that that can be
handled by hid-multitouch.c and we get proper multi-touch support.This commit changes the hid_device_id for the SW5-012 keyboard dock to
only match on hid devices from the HID_GROUP_GENERIC group, this way
hid-ite will not bind the the mouse/multi-touch interface which has
HID_GROUP_MULTITOUCH_WIN_8 as group.
This fixes the regression to mouse-emulation mode introduced by adding
the keyboard dock USB id.Cc: stable@vger.kernel.org
Fixes: 8f18eca9ebc5 ("HID: ite: Add USB id match for Acer SW5-012 keyboard dock")
Reported-by: Zdeněk Rampas
Signed-off-by: Hans de Goede
Signed-off-by: Benjamin Tissoires
Signed-off-by: Greg Kroah-Hartman
01 Feb, 2020
10 commits
-
[ Upstream commit 20eee6e5af35d9586774e80b6e0b1850e7cc9899 ]
The `connected` value for wired devices was not properly initialized,
it must be set to `true` upon creation, because wired devices do not
generate connection events.When a raw client (the Steam Client) uses the device, the input device
is destroyed. Then, when the raw client finishes, it must be recreated.
But since the `connected` variable was false this never happended.Signed-off-by: Rodrigo Rivas Costa
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin -
[ Upstream commit 1479a82d82df68dfac29c72c774cb8bdc17d4eb1 ]
Added Tiger Lake PCI device ID to the supported device list.
Signed-off-by: Srinivas Pandruvada
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin -
[ Upstream commit 306d5acbfc66e7cccb4d8f91fc857206b8df80d1 ]
1002 if ((quirks & MT_QUIRK_IGNORE_DUPLICATES) && mt) {
1003 struct input_mt_slot *i_slot = &mt->slots[slotnum];
1004
1005 if (input_mt_is_active(i_slot) &&
1006 input_mt_is_used(mt, i_slot))
1007 return -EAGAIN;
1008 }We previously assumed 'mt' could be null (see line 1002).
The following situation is similar, so add a judgement.
Signed-off-by: Pan Zhang
Signed-off-by: Benjamin Tissoires
Signed-off-by: Sasha Levin -
[ Upstream commit fe4e940f0f91b4a506f048b42e00386f5ad322b6 ]
A new PID is in use for repaired MobileStudio Pro devices. Add it to the
list of devices that need special-casing in wacom_wac_pad_event.Signed-off-by: Jason Gerecke
Signed-off-by: Benjamin Tissoires
Signed-off-by: Sasha Levin -
[ Upstream commit abb33ee8a8c0d146b4b2c52937dc86a15ec92d05 ]
Add Comet Lake H into ishtp support list.
Signed-off-by: Even Xu
Acked-by: Srinivas Pandruvada
Signed-off-by: Benjamin Tissoires
Signed-off-by: Sasha Levin -
[ Upstream commit fd0913768701612fc2b8ab9c8a5c019133e8d978 ]
Apply it to the Lenovo Y720 gaming laptop I2C peripheral then.
This fixes dmesg being flooded with errors visible on un-suspend
in Linux Mint 19 Cinnamon.Example of error log:
[ 4.326588] i2c_hid i2c-ITE33D1:00: i2c_hid_get_input: incomplete report (2/4)
[ 4.326845] i2c_hid i2c-ITE33D1:00: i2c_hid_get_input: incomplete report (2/4)
[ 4.327095] i2c_hid i2c-ITE33D1:00: i2c_hid_get_input: incomplete report (2/4)
[ 4.327341] i2c_hid i2c-ITE33D1:00: i2c_hid_get_input: incomplete report (2/4)
[ 4.327609] i2c_hid i2c-ITE33D1:00: i2c_hid_get_input: incomplete report (2/4)Example of fixed log (debug on)
[ 3731.333183] i2c_hid i2c-ITE33D1:00: input: 02 00
[ 3731.333581] i2c_hid i2c-ITE33D1:00: input: 02 00
[ 3731.333842] i2c_hid i2c-ITE33D1:00: input: 02 00
[ 3731.334107] i2c_hid i2c-ITE33D1:00: input: 02 00
[ 3731.334367] i2c_hid i2c-ITE33D1:00: input: 02 00[jkosina@suse.cz: rebase onto more recent codebase]
Signed-off-by: Pavel Balan
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin -
[ Upstream commit c07a0254c89e4bb69ca781cd488baa5b628e2754 ]
At least on a T100HA an Asus vendor-page usage-code 0xff event is send on
every suspend and again on resume, resulting in the following warning:asus 0003:0B05:1807.0002: Unmapped Asus vendor usagepage code 0xff
being logged twice on every suspend/resume.
This commit silences the "Unmapped Asus vendor usagepage code ..."
warning for usage-code 0xff to avoid these warnings being logged.Signed-off-by: Hans de Goede
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin -
[ Upstream commit 8f18eca9ebc57d6b150237033f6439242907e0ba ]
The Acer SW5-012 2-in-1 keyboard dock uses a Synaptics S91028 touchpad
which is connected to an ITE 8595 USB keyboard controller chip.This keyboard has the same quirk for its rfkill / airplane mode hotkey as
other keyboards with the ITE 8595 chip, it only sends a single release
event when pressed and released, it never sends a press event.This commit adds this keyboards USB id to the hid-ite id-table, fixing
the rfkill key not working on this keyboard.Signed-off-by: Hans de Goede
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin -
[ Upstream commit c62f7cd8ed066a93a243643ebf57ca99f754388e ]
Without the quirk, joystick shows up as single controller
for both first and second player pads/pins.Signed-off-by: Priit Laes
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin -
[ Upstream commit 348b80b273fbf4ce2a307f9e38eadecf37828cad ]
Add multitouch support for LG MELF I2C touchscreen.
Apply the same workaround as LG USB touchscreen.Signed-off-by: Aaron Ma
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin
18 Jan, 2020
1 commit
-
[ Upstream commit 9e635c2851df6caee651e589fbf937b637973c91 ]
hidraw and uhid device nodes are always available for writing so we should
always report EPOLLOUT and EPOLLWRNORM bits, not only in the cases when
there is nothing to read.Reported-by: Linus Torvalds
Fixes: be54e7461ffdc ("HID: uhid: Fix returning EPOLLOUT from uhid_char_poll")
Fixes: 9f3b61dc1dd7b ("HID: hidraw: Fix returning EPOLLOUT from hidraw_poll")
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin
15 Jan, 2020
5 commits
-
commit 18a1b06e5b91d47dc86c0a66a762646ea7c5d141 upstream.
The open method of hiddev handler fails to bring the device out of
autosuspend state as was promised in 0361a28d3f9a, as it actually has 2
blocks that try to start the transport (call hid_hw_open()) with both
being guarded by the "open" counter, so the 2nd block is never executed as
the first block increments the counter so it is never at 0 when we check
it for the second block.Additionally hiddev_open() was leaving counter incremented on errors,
causing the device to never be reopened properly if there was ever an
error.Let's fix all of this by factoring out code that creates client structure
and powers up the device into a separate function that is being called
from usbhid_open() with the "existancelock" being held.Fixes: 0361a28d3f9a ("HID: autosuspend support for USB HID")
Signed-off-by: Dmitry Torokhov
Signed-off-by: Benjamin Tissoires
Signed-off-by: Greg Kroah-Hartman -
commit 4f3882177240a1f55e45a3d241d3121341bead78 upstream.
We should not be leaving half-mapped usages with potentially invalid
keycodes, as that may confuse hidinput_find_key() when the key is located
by index, which may end up feeding way too large keycode into the VT
keyboard handler and cause OOB write there:BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline]
BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722
...
kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline]
kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495
input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118
input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145
input_pass_values drivers/input/input.c:949 [inline]
input_set_keycode+0x290/0x320 drivers/input/input.c:954
evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882
evdev_do_ioctl drivers/input/evdev.c:1150 [inline]Cc: stable@vger.kernel.org
Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com
Signed-off-by: Dmitry Torokhov
Tested-by: Benjamin Tissoires
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 9f3b61dc1dd7b81e99e7ed23776bb64a35f39e1a upstream.
When polling a connected /dev/hidrawX device, it is useful to get the
EPOLLOUT when writing is possible. Since writing is possible as soon as
the device is connected, always return it.Right now EPOLLOUT is only returned when there are also input reports
are available. This works if devices start sending reports when
connected, but some HID devices might need an output report first before
sending any input reports. This change will allow using EPOLLOUT here as
well.Fixes: 378b80370aa1 ("hidraw: Return EPOLLOUT from hidraw_poll")
Signed-off-by: Marcel Holtmann
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit be54e7461ffdc5809b67d2aeefc1ddc9a91470c7 upstream.
Always return EPOLLOUT from uhid_char_poll to allow polling /dev/uhid
for writable state.Fixes: 1f9dec1e0164 ("HID: uhid: allow poll()'ing on uhid devices")
Signed-off-by: Marcel Holtmann
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman -
commit 8ec321e96e056de84022c032ffea253431a83c3c upstream.
The syzbot fuzzer found a slab-out-of-bounds bug in the HID report
handler. The bug was caused by a report descriptor which included a
field with size 12 bits and count 4899, for a total size of 7349
bytes.The usbhid driver uses at most a single-page 4-KB buffer for reports.
In the test there wasn't any problem about overflowing the buffer,
since only one byte was received from the device. Rather, the bug
occurred when the HID core tried to extract the data from the report
fields, which caused it to try reading data beyond the end of the
allocated buffer.This patch fixes the problem by rejecting any report whose total
length exceeds the HID_MAX_BUFFER_SIZE limit (minus one byte to allow
for a possible report index). In theory a device could have a report
longer than that, but if there was such a thing we wouldn't handle it
correctly anyway.Reported-and-tested-by: syzbot+09ef48aa58261464b621@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
CC:
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
09 Jan, 2020
1 commit
-
commit fd70466d37bf3fe0118d18c56ddde85b428f86cf upstream.
Commit 52cf93e63ee6 ("HID: i2c-hid: Don't reset device upon system
resume") fixes many touchpads and touchscreens, however ALPS touchpads
start to trigger IRQ storm after system resume.Since it's total silence from ALPS, let's bring the old behavior back
to ALPS touchpads.Fixes: 52cf93e63ee6 ("HID: i2c-hid: Don't reset device upon system resume")
Signed-off-by: Kai-Heng Feng
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
05 Jan, 2020
5 commits
-
[ Upstream commit 8725aa4fa7ded30211ebd28bb1c9bae806eb3841 ]
In the event that the RMI device is unreachable, the calls to rmi_set_mode() or
rmi_set_page() will fail before registering the RMI transport device. When the
device is removed, rmi_remove() will call rmi_unregister_transport_device()
which will attempt to access the rmi_dev pointer which was not set.
This patch adds a check of the RMI_STARTED bit before calling
rmi_unregister_transport_device(). The RMI_STARTED bit is only set
after rmi_register_transport_device() completes successfully.The kernel oops was reported in this message:
https://www.spinics.net/lists/linux-input/msg58433.html[jkosina@suse.cz: reworded changelog as agreed with Andrew]
Signed-off-by: Andrew Duggan
Reported-by: Federico Cerutti
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin -
[ Upstream commit 2dbc6f113acd74c66b04bf49fb027efd830b1c5a ]
Per Microsoft spec, usage 0xC5 (page 0xFF) returns a blob containing
data used to verify the touchpad as a Windows Precision Touchpad.0x85, REPORTID_PTPHQA, // REPORT_ID (PTPHQA)
0x09, 0xC5, // USAGE (Vendor Usage 0xC5)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (0xff)
0x75, 0x08, // REPORT_SIZE (8)
0x96, 0x00, 0x01, // REPORT_COUNT (0x100 (256))
0xb1, 0x02, // FEATURE (Data,Var,Abs)However, some devices, namely Microsoft's Surface line of products
instead implement a "segmented device certification report" (usage 0xC6)
which returns the same report, but in smaller chunks.0x06, 0x00, 0xff, // USAGE_PAGE (Vendor Defined)
0x85, REPORTID_PTPHQA, // REPORT_ID (PTPHQA)
0x09, 0xC6, // USAGE (Vendor usage for segment #)
0x25, 0x08, // LOGICAL_MAXIMUM (8)
0x75, 0x08, // REPORT_SIZE (8)
0x95, 0x01, // REPORT_COUNT (1)
0xb1, 0x02, // FEATURE (Data,Var,Abs)
0x09, 0xC7, // USAGE (Vendor Usage)
0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (0xff)
0x95, 0x20, // REPORT_COUNT (32)
0xb1, 0x02, // FEATURE (Data,Var,Abs)By expanding Win8 touchpad detection to also look for the segmented
report, all Surface touchpads are now properly recognized by
hid-multitouch.Signed-off-by: Blaž Hrastnik
Signed-off-by: Benjamin Tissoires
Signed-off-by: Sasha Levin -
[ Upstream commit 0c8432236dea20a95f68fa17989ea3f8af0186a5 ]
On some ThinkPad L390 some raydium 3118 touchscreen devices
doesn't response any data after reset, but some does.Add this ID to no irq quirk,
then don't wait for any response alike on these touchscreens.
All kinds of raydium 3118 devices work fine.BugLink: https://bugs.launchpad.net/bugs/1849721
Signed-off-by: Aaron Ma
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin -
[ Upstream commit 61005d65b6c7dcf61c19516e6ebe5acc02d2cdda ]
My Logitech M185 (PID:4038) 2.4 GHz wireless HID++ mouse is causing
intermittent errors like these in the log:[11091.034857] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09
[12388.031260] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09
[16613.718543] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09
[23529.938728] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09We are already silencing error-code 0x09 (HIDPP_ERROR_RESOURCE_ERROR)
errors in other places, lets do the same in
hidpp20_batterylevel_get_battery_capacity to remove these harmless,
but scary looking errors from the dmesg output.Signed-off-by: Hans de Goede
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin -
[ Upstream commit f1a0094cbbe97a5f8aca7bdc64bfe43ac9dc6879 ]
The PixArt OEM mouse disconnets/reconnects every minute on
Linux. All contents of dmesg are repetitive:[ 1465.810014] usb 1-2.2: USB disconnect, device number 20
[ 1467.431509] usb 1-2.2: new low-speed USB device number 21 using xhci_hcd
[ 1467.654982] usb 1-2.2: New USB device found, idVendor=03f0,idProduct=1f4a, bcdDevice= 1.00
[ 1467.654985] usb 1-2.2: New USB device strings: Mfr=1, Product=2,SerialNumber=0
[ 1467.654987] usb 1-2.2: Product: HP USB Optical Mouse
[ 1467.654988] usb 1-2.2: Manufacturer: PixArt
[ 1467.699722] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:07.1/0000:05:00.3/usb1/1-2/1-2.2/1-2.2:1.0/0003:03F0:1F4A.0012/input/input19
[ 1467.700124] hid-generic 0003:03F0:1F4A.0012: input,hidraw0: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:05:00.3-2.2/input0So add HID_QUIRK_ALWAYS_POLL for this one as well.
Test the patch, the mouse is no longer disconnected and there are no
duplicate logs in dmesg.Reference:
https://github.com/sriemer/fix-linux-mouseSigned-off-by: Jinke Fan
Signed-off-by: Jiri Kosina
Signed-off-by: Sasha Levin
05 Dec, 2019
1 commit
-
commit 1cb0d2aee26335d0bccf29100c7bed00ebece851 upstream.
Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation
to Main item") adds support for Usage Page item after Usage ID items
(such as keyboards manufactured by Primax).Usage Page concatenation in Main item works well for following report
descriptor patterns:USAGE_PAGE (Keyboard) 05 07
USAGE_MINIMUM (Keyboard LeftControl) 19 E0
USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (8) 95 08
INPUT (Data,Var,Abs) 81 02-------------
USAGE_MINIMUM (Keyboard LeftControl) 19 E0
USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (8) 95 08
USAGE_PAGE (Keyboard) 05 07
INPUT (Data,Var,Abs) 81 02But it makes the parser act wrong for the following report
descriptor pattern(such as some Gamepads):USAGE_PAGE (Button) 05 09
USAGE (Button 1) 09 01
USAGE (Button 2) 09 02
USAGE (Button 4) 09 04
USAGE (Button 5) 09 05
USAGE (Button 7) 09 07
USAGE (Button 8) 09 08
USAGE (Button 14) 09 0E
USAGE (Button 15) 09 0F
USAGE (Button 13) 09 0D
USAGE_PAGE (Consumer Devices) 05 0C
USAGE (Back) 0a 24 02
USAGE (HomePage) 0a 23 02
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
REPORT_SIZE (1) 75 01
REPORT_COUNT (11) 95 0B
INPUT (Data,Var,Abs) 81 02With Usage Page concatenation in Main item, parser recognizes all the
11 Usages as consumer keys, it is not the HID device's real intention.This patch checks whether Usage Page is really defined after Usage ID
items by comparing usage page using status.Usage Page concatenation on currently defined Usage Page will always
do in local parsing when Usage ID items encountered.When Main item is parsing, concatenation will do again with last
defined Usage Page if this page has not been used in the previous
usages concatenation.Signed-off-by: Candle Sun
Signed-off-by: Nianfu Bai
Cc: Benjamin Tissoires
Signed-off-by: Jiri Kosina
Cc: Siarhei Vishniakou
Signed-off-by: Greg Kroah-Hartman
08 Nov, 2019
1 commit
-
Pull HID fixes from Jiri Kosina:
"Two fixes for the HID subsystem:- regression fix for i2c-hid power management (Hans de Goede)
- signed vs unsigned API fix for Wacom driver (Jason Gerecke)"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
HID: wacom: generic: Treat serial number and related fields as unsigned
HID: i2c-hid: Send power-on command after reset
07 Nov, 2019
1 commit
-
The HID descriptors for most Wacom devices oddly declare the serial
number and other related fields as signed integers. When these numbers
are ingested by the HID subsystem, they are automatically sign-extended
into 32-bit integers. We treat the fields as unsigned elsewhere in the
kernel and userspace, however, so this sign-extension causes problems.
In particular, the sign-extended tool ID sent to userspace as ABS_MISC
does not properly match unsigned IDs used by xf86-input-wacom and libwacom.We introduce a function 'wacom_s32tou' that can undo the automatic sign
extension performed by 'hid_snto32'. We call this function when processing
the serial number and related fields to ensure that we are dealing with
and reporting the unsigned form. We opt to use this method rather than
adding a descriptor fixup in 'wacom_hid_usage_quirk' since it should be
more robust in the face of future devices.Ref: https://github.com/linuxwacom/input-wacom/issues/134
Fixes: f85c9dc678 ("HID: wacom: generic: Support tool ID and additional tool types")
CC: # v4.10+
Signed-off-by: Jason Gerecke
Reviewed-by: Aaron Armstrong Skomra
Signed-off-by: Jiri Kosina
03 Nov, 2019
1 commit
-
Before commit 67b18dfb8cfc ("HID: i2c-hid: Remove runtime power
management"), any i2c-hid touchscreens would typically be runtime-suspended
between the driver loading and Xorg or a Wayland compositor opening it,
causing it to be resumed again. This means that before this change,
we would call i2c_hid_set_power(OFF), i2c_hid_set_power(ON) before the
graphical session would start listening to the touchscreen.It turns out that at least some SIS touchscreens, such as the one found
on the Asus T100HA, need a power-on command after reset, otherwise they
will not send any events.Fixes: 67b18dfb8cfc ("HID: i2c-hid: Remove runtime power management")
Cc: Kai-Heng Feng
Signed-off-by: Hans de Goede
Signed-off-by: Jiri Kosina
28 Oct, 2019
1 commit
-
Pull HID fixes from Jiri Kosina:
- HID++ device support regression fixes (race condition during cleanup,
device detection fix, opps fix) from Andrey Smirnov- disable PM on i2c-hid, as it's causing problems with a lot of
devices; other OSes apparently don't implement/enable it either; from
Kai-Heng Feng- error handling fix in intel-ish driver, from Zhang Lixu
- syzbot fuzzer fix for HID core code from Alan Stern
- a few other tiny fixups (printk message cleanup, new device ID)
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
HID: i2c-hid: add Trekstor Primebook C11B to descriptor override
HID: logitech-hidpp: do all FF cleanup in hidpp_ff_destroy()
HID: logitech-hidpp: rework device validation
HID: logitech-hidpp: split g920_get_config()
HID: i2c-hid: Remove runtime power management
HID: intel-ish-hid: fix wrong error handling in ishtp_cl_alloc_tx_ring()
HID: google: add magnemite/masterball USB ids
HID: Fix assumption that devices have inputs
HID: prodikeys: make array keys static const, makes object smaller
HID: fix error message in hid_open_report()
18 Oct, 2019
5 commits
-
The Primebook C11B uses the SIPODEV SP1064 touchpad. There are 2 versions
of this 2-in-1 and the touchpad in the older version does not supply
descriptors, so it has to be added to the override list.Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede
Signed-off-by: Benjamin Tissoires -
All of the FF-related resources belong to corresponding FF device, so
they should be freed as a part of hidpp_ff_destroy() to avoid
potential race condidions.Fixes: ff21a635dd1a ("HID: logitech-hidpp: Force feedback support for the Logitech G920")
Suggested-by: Benjamin Tissoires
Signed-off-by: Andrey Smirnov
Cc: Jiri Kosina
Cc: Benjamin Tissoires
Cc: Henrik Rydberg
Cc: Pierre-Loup A. Griffais
Cc: Austin Palmer
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 5.2+
Signed-off-by: Benjamin Tissoires -
G920 device only advertises REPORT_ID_HIDPP_LONG and
REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying
for REPORT_ID_HIDPP_SHORT with optional=false will always fail and
prevent G920 to be recognized as a valid HID++ device.To fix this and improve some other aspects, modify
hidpp_validate_device() as follows:- Inline the code of hidpp_validate_report() to simplify
distingushing between non-present and invalid report descriptors- Drop the check for id >= HID_MAX_IDS || id < 0 since all of our
IDs are static and known to satisfy that at compile time- Change the algorithms to check all possible report
types (including very long report) and deem the device as a valid
HID++ device if it supports at least one- Treat invalid report length as a hard stop for the validation
algorithm, meaning that if any of the supported reports has
invalid length we assume the worst and treat the device as a
generic HID device.- Fold initialization of hidpp->very_long_report_length into
hidpp_validate_device() since it already fetches very long report
length and validates its valueFixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to be handled by this module")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191
Reported-by: Sam Bazely
Signed-off-by: Andrey Smirnov
Cc: Jiri Kosina
Cc: Benjamin Tissoires
Cc: Henrik Rydberg
Cc: Pierre-Loup A. Griffais
Cc: Austin Palmer
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 5.2+
Signed-off-by: Benjamin Tissoires -
Original version of g920_get_config() contained two kind of actions:
1. Device specific communication to query/set some parameters
which requires active communication channel with the device,
or, put in other way, for the call to be sandwiched between
hid_device_io_start() and hid_device_io_stop().2. Input subsystem specific FF controller initialization which, in
order to access a valid 'struct hid_input' via
'hid->inputs.next', requires claimed hidinput which means be
executed after the call to hid_hw_start() with connect_mask
containing HID_CONNECT_HIDINPUT.Location of g920_get_config() can only fulfill requirements for #1 and
not #2, which might result in following backtrace:[ 88.312258] logitech-hidpp-device 0003:046D:C262.0005: HID++ 4.2 device connected.
[ 88.320298] BUG: kernel NULL pointer dereference, address: 0000000000000018
[ 88.320304] #PF: supervisor read access in kernel mode
[ 88.320307] #PF: error_code(0x0000) - not-present page
[ 88.320309] PGD 0 P4D 0
[ 88.320315] Oops: 0000 [#1] SMP PTI
[ 88.320320] CPU: 1 PID: 3080 Comm: systemd-udevd Not tainted 5.4.0-rc1+ #31
[ 88.320322] Hardware name: Apple Inc. MacBookPro11,1/Mac-189A3D4F975D5FFC, BIOS 149.0.0.0.0 09/17/2018
[ 88.320334] RIP: 0010:hidpp_probe+0x61f/0x948 [hid_logitech_hidpp]
[ 88.320338] Code: 81 00 00 48 89 ef e8 f0 d6 ff ff 41 89 c6 85 c0 75 b5 0f b6 44 24 28 48 8b 5d 00 88 44 24 1e 89 44 24 0c 48 8b 83 18 1c 00 00 8b 48 18 48 8b 83 10 19 00 00 48 8b 40 40 48 89 0c 24 0f b7 80
[ 88.320341] RSP: 0018:ffffb0a6824aba68 EFLAGS: 00010246
[ 88.320345] RAX: 0000000000000000 RBX: ffff93a50756e000 RCX: 0000000000010408
[ 88.320347] RDX: 0000000000000000 RSI: ffff93a51f0ad0a0 RDI: 000000000002d0a0
[ 88.320350] RBP: ffff93a50416da28 R08: ffff93a50416da70 R09: ffff93a50416da70
[ 88.320352] R10: 000000148ae9e60c R11: 00000000000f1525 R12: ffff93a50756e000
[ 88.320354] R13: ffff93a50756f8d0 R14: 0000000000000000 R15: ffff93a50756fc38
[ 88.320358] FS: 00007f8d8c1e0940(0000) GS:ffff93a51f080000(0000) knlGS:0000000000000000
[ 88.320361] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 88.320363] CR2: 0000000000000018 CR3: 00000003996d8003 CR4: 00000000001606e0
[ 88.320366] Call Trace:
[ 88.320377] ? _cond_resched+0x15/0x30
[ 88.320387] ? create_pinctrl+0x2f/0x3c0
[ 88.320393] ? kernfs_link_sibling+0x94/0xe0
[ 88.320398] ? _cond_resched+0x15/0x30
[ 88.320402] ? kernfs_activate+0x5f/0x80
[ 88.320406] ? kernfs_add_one+0xe2/0x130
[ 88.320411] hid_device_probe+0x106/0x170
[ 88.320419] really_probe+0x147/0x3c0
[ 88.320424] driver_probe_device+0xb6/0x100
[ 88.320428] device_driver_attach+0x53/0x60
[ 88.320433] __driver_attach+0x8a/0x150
[ 88.320437] ? device_driver_attach+0x60/0x60
[ 88.320440] bus_for_each_dev+0x78/0xc0
[ 88.320445] bus_add_driver+0x14d/0x1f0
[ 88.320450] driver_register+0x6c/0xc0
[ 88.320453] ? 0xffffffffc0d67000
[ 88.320457] __hid_register_driver+0x4c/0x80
[ 88.320464] do_one_initcall+0x46/0x1f4
[ 88.320469] ? _cond_resched+0x15/0x30
[ 88.320474] ? kmem_cache_alloc_trace+0x162/0x220
[ 88.320481] ? do_init_module+0x23/0x230
[ 88.320486] do_init_module+0x5c/0x230
[ 88.320491] load_module+0x26e1/0x2990
[ 88.320502] ? ima_post_read_file+0xf0/0x100
[ 88.320508] ? __do_sys_finit_module+0xaa/0x110
[ 88.320512] __do_sys_finit_module+0xaa/0x110
[ 88.320520] do_syscall_64+0x5b/0x180
[ 88.320525] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 88.320528] RIP: 0033:0x7f8d8d1f01fd
[ 88.320532] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 5b 8c 0c 00 f7 d8 64 89 01 48
[ 88.320535] RSP: 002b:00007ffefa3bb068 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 88.320539] RAX: ffffffffffffffda RBX: 000055922040cb40 RCX: 00007f8d8d1f01fd
[ 88.320541] RDX: 0000000000000000 RSI: 00007f8d8ce4984d RDI: 0000000000000006
[ 88.320543] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000007
[ 88.320545] R10: 0000000000000006 R11: 0000000000000246 R12: 00007f8d8ce4984d
[ 88.320547] R13: 0000000000000000 R14: 000055922040efc0 R15: 000055922040cb40
[ 88.320551] Modules linked in: hid_logitech_hidpp(+) fuse rfcomm ccm xt_CHECKSUM xt_MASQUERADE bridge stp llc nf_nat_tftp nf_conntrack_tftp nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat tun iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables cmac bnep sunrpc dm_crypt nls_utf8 hfsplus intel_rapl_msr intel_rapl_common ath9k_htc ath9k_common x86_pkg_temp_thermal intel_powerclamp b43 ath9k_hw coretemp snd_hda_codec_hdmi cordic kvm_intel snd_hda_codec_cirrus mac80211 snd_hda_codec_generic ledtrig_audio kvm snd_hda_intel snd_intel_nhlt irqbypass snd_hda_codec btusb btrtl snd_hda_core ath btbcm ssb snd_hwdep btintel snd_seq crct10dif_pclmul iTCO_wdt snd_seq_device crc32_pclmul bluetooth mmc_core iTCO_vendor_support joydev cfg80211
[ 88.320602] applesmc ghash_clmulni_intel ecdh_generic snd_pcm input_polldev intel_cstate ecc intel_uncore thunderbolt snd_timer i2c_i801 libarc4 rfkill intel_rapl_perf lpc_ich mei_me pcspkr bcm5974 snd bcma mei soundcore acpi_als sbs kfifo_buf sbshc industrialio apple_bl i915 i2c_algo_bit drm_kms_helper drm uas crc32c_intel usb_storage video hid_apple
[ 88.320630] CR2: 0000000000000018
[ 88.320633] ---[ end trace 933491c8a4fadeb7 ]---
[ 88.320642] RIP: 0010:hidpp_probe+0x61f/0x948 [hid_logitech_hidpp]
[ 88.320645] Code: 81 00 00 48 89 ef e8 f0 d6 ff ff 41 89 c6 85 c0 75 b5 0f b6 44 24 28 48 8b 5d 00 88 44 24 1e 89 44 24 0c 48 8b 83 18 1c 00 00 8b 48 18 48 8b 83 10 19 00 00 48 8b 40 40 48 89 0c 24 0f b7 80
[ 88.320647] RSP: 0018:ffffb0a6824aba68 EFLAGS: 00010246
[ 88.320650] RAX: 0000000000000000 RBX: ffff93a50756e000 RCX: 0000000000010408
[ 88.320652] RDX: 0000000000000000 RSI: ffff93a51f0ad0a0 RDI: 000000000002d0a0
[ 88.320655] RBP: ffff93a50416da28 R08: ffff93a50416da70 R09: ffff93a50416da70
[ 88.320657] R10: 000000148ae9e60c R11: 00000000000f1525 R12: ffff93a50756e000
[ 88.320659] R13: ffff93a50756f8d0 R14: 0000000000000000 R15: ffff93a50756fc38
[ 88.320662] FS: 00007f8d8c1e0940(0000) GS:ffff93a51f080000(0000) knlGS:0000000000000000
[ 88.320664] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 88.320667] CR2: 0000000000000018 CR3: 00000003996d8003 CR4: 00000000001606e0To solve this issue:
1. Split g920_get_config() such that all of the device specific
communication remains a part of the function and input subsystem
initialization bits go to hidpp_ff_init()2. Move call to hidpp_ff_init() from being a part of
g920_get_config() to be the last step of .probe(), right after a
call to hid_hw_start() with connect_mask containing
HID_CONNECT_HIDINPUT.Fixes: 91cf9a98ae41 ("HID: logitech-hidpp: make .probe usbhid capable")
Signed-off-by: Andrey Smirnov
Tested-by: Sam Bazley
Cc: Jiri Kosina
Cc: Benjamin Tissoires
Cc: Henrik Rydberg
Cc: Pierre-Loup A. Griffais
Cc: Austin Palmer
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # 5.2+
Signed-off-by: Benjamin Tissoires -
Runtime power management in i2c-hid brings lots of issues, such as:
- When transitioning from display manager to desktop session, i2c-hid
was closed and opened, so the device was set to SLEEP and ON in a short
period. Vendors confirmed that their devices can't handle fast ON/SLEEP
command because Windows doesn't have this behavior.- When rebooting, i2c-hid was closed, and the driver core put the device
back to full power before shutdown. This behavior also triggers a quick
SLEEP and ON commands that some devices can't handle, renders an
unusable touchpad after reboot.- Most importantly, my power meter reports little to none energy saving
when i2c-hid is runtime suspended.So let's remove runtime power management since there is no actual
benefit.Signed-off-by: Kai-Heng Feng
Acked-by: Hans de Goede
Signed-off-by: Benjamin Tissoires
16 Oct, 2019
1 commit
-
When allocating tx ring buffers failed, should free tx buffers, not rx buffers.
Signed-off-by: Zhang Lixu
Acked-by: Srinivas Pandruvada
Signed-off-by: Jiri Kosina
11 Oct, 2019
1 commit
-
Add 2 additional hammer-like devices.
Signed-off-by: Nicolas Boichat
Signed-off-by: Jiri Kosina
04 Oct, 2019
1 commit
-
The syzbot fuzzer found a slab-out-of-bounds write bug in the hid-gaff
driver. The problem is caused by the driver's assumption that the
device must have an input report. While this will be true for all
normal HID input devices, a suitably malicious device can violate the
assumption.The same assumption is present in over a dozen other HID drivers.
This patch fixes them by checking that the list of hid_inputs for the
hid_device is nonempty before allowing it to be used.Reported-and-tested-by: syzbot+403741a091bf41d4ae79@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
CC:
Signed-off-by: Benjamin Tissoires
02 Oct, 2019
1 commit
-
Simplify the ring buffer handling with the in-place API.
Also avoid the dynamic allocation and the memory leak in the channel
callback function.Signed-off-by: Dexuan Cui
Acked-by: Jiri Kosina
Signed-off-by: Sasha Levin
