kernel/git/stable/linux-stable.git/drivers/hid, branch linux-6.12.y

HID: multitouch: reclassify HTIX5288 to WIN_8_FORCE_MULTI_INPUT_NSMU

2026-09-14T11:32:46+00:00

[ Upstream commit 69226cd6fad7a07370ec9a009af1c174de7635c5 ] Commit b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad") assigned MT_CLS_NSMU to the HTIX5288 (0911:5288). This was necessary because the device sometimes fails to send touch release signals when transitioning from >=2 fingers to <2 fingers, and MT_QUIRK_NOT_SEEN_MEANS_UP fixes stuck touches by treating missing contacts as released. However, MT_CLS_NSMU only carries MT_QUIRK_NOT_SEEN_MEANS_UP. It lacks MT_QUIRK_CONTACT_CNT_ACCURATE and MT_QUIRK_IGNORE_DUPLICATES. As a result, after a two-finger scroll finger lift, the device still reports stale coordinates from the released contact in subsequent frames, and the driver overwrites the remaining active slot with those frozen coordinates. The remaining finger appears stuck at the lift position until all fingers are lifted. This was confirmed via evtest on Arch Linux 7.1.3: after TRACKING_ID=-1 for the released slot, every subsequent frame contained duplicate position pairs -- the real moving finger's coordinates followed by the lifted finger's frozen position, both attributed to the active slot. Reclassify the device to MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU (0x0018), which preserves the original MT_QUIRK_NOT_SEEN_MEANS_UP fix while adding the necessary Win8 quirks (CONTACT_CNT_ACCURATE, IGNORE_DUPLICATES), preventing stale coordinate contamination. The additional FORCE_MULTI_INPUT flag is harmless here: it separates the mouse and touchpad collections into distinct input devices, which is the standard behavior libinput already expects. Fixes: b5e65ae557da ("HID: multitouch: Add quirk for Hantick 5288 touchpad") Signed-off-by: Xianglin Lin <1021538027@qq.com> Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: lg4ff: validate report length before fixed offsets

2026-09-14T11:32:30+00:00

[ Upstream commit be00988cce4ed44db1e61231d0ab71a64bab44cd ] lg4ff_raw_event() rewrites fixed report offsets when combined pedals are enabled. It currently assumes that each product report contains every source and destination byte used by the rewrite. Return without rewriting a short report before each product-specific access. Apply the same bound to the computed offset path. Fixes: c832f86effbc ("HID: hid-logitech: Add combined pedal support Logitech wheels") Signed-off-by: Jiancheng Huang Assisted-by: Codex:gpt-5.6-luna Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: i2c-hid: goodix: Disable VDD on VDDIO enable failure

2026-09-14T11:32:30+00:00

[ Upstream commit 8e2c560faea0220664169f7be4b498915ea1469f ] If enabling VDDIO fails after VDD has been enabled, the power-up path returns without disabling VDD. This leaves the regulator enabled and its enable count unbalanced. Disable VDD before returning the VDDIO error. Fixes: eb16f59e8e58 ("HID: i2c-hid: goodix: Add mainboard-vddio-supply") Signed-off-by: Chao Huang Reviewed-by: Douglas Anderson Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: i2c-hid: Fix "(null)" output when reading report descriptor fails

2026-09-14T11:32:30+00:00

[ Upstream commit 8da0f0951deec9f0728ed2d9c54ded1c344b7542 ] When i2c-hid fails to read the HID report descriptor during device initialization, the error message prints as: hid (null): reading report descriptor failed The HID device name is set in hid_add_device() after calling hdev->ll_driver->parse(), so when i2c_hid_parse() fails and calls hid_err(), the device name has not been set yet, resulting in "(null)" output. Use dev_err(&client->dev, ...) instead of hid_err(hid, ...) because the I2C client device is fully initialized with a proper name, providing meaningful error messages for debugging. Before: hid (null): reading report descriptor failed After: i2c_hid i2c-TPD0001:00: reading report descriptor failed Fixes: 4a200c3b9a40 ("HID: i2c-hid: introduce HID over i2c specification implementation") Signed-off-by: Ai Chao Reviewed-by: Mario Limonciello (AMD) Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: synchronize input before cleaning up a failed probe

2026-09-14T11:32:29+00:00

[ Upstream commit 207853d46f7ef2e28042344a1468da8754c3ddbf ] hid_device_io_start() allows reports to run concurrently with probe. If the probe subsequently fails, __hid_device_probe() releases driver resources and clears hdev->driver without first excluding those report callbacks. For example, a report may enter hidraw_report_event() while the failure path frees the associated hidraw object, leading to a use-after-free when the report takes the object's list lock. Stop input before performing failed-probe cleanup. This reacquires driver_input_lock and waits for any report callback already in progress. Fixes: c849a6143bec ("HID: Separate struct hid_device's driver_lock into two locks.") Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858 Signed-off-by: Yousef Alhouseen Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver

2026-09-14T11:32:29+00:00

[ Upstream commit fd7c67d05fb695b1deb07f9e213dd7e80e3a8427 ] Move the _DSM call that gets the HID descriptor address from i2c-hid-acpi.c into i2c-hid-acpi.h as a static inline so both the ACPI and the new PRP0001 driver can use it. While refactoring, move the blacklist check and the _DSM call to the top of probe() to avoid a pointless alloc when the device is blacklisted or does not implement the _DSM. Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3, are declared with _HID "PRP0001" and _DSD compatible "hid-over-i2c" but lack "hid-descr-addr" from the _DSD and provide the HID descriptor address only through an ACPI _DSM. The OF driver fails to probe them because it requires hid-descr-addr. Add a new driver that handles these devices by calling the shared _DSM helper. Link: https://lore.kernel.org/tencent_F6FC553D1BB737FC00062AD0FEF43C580F0A@qq.com Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules") Signed-off-by: 谢致邦 (XIE Zhibang) Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: roccat: bound device-supplied profile index

2026-09-14T11:31:44+00:00

[ Upstream commit 43fae42628a8c10fa8981773d7ec9f1a367821a7 ] kone_keep_values_up_to_date() and kone_profile_activated() use an 8-bit, device-supplied profile value as an index into the 5-element kone->profiles[] array without a range check. A malicious USB device claiming the Roccat Kone id can send a switch-profile event (or a startup_profile read at probe) with an out-of-range value and make the driver read out of bounds; the result is exposed via the actual_dpi sysfs attribute. Reject out-of-range indices in both paths. This was found with static analysis and confirmed with the KUnit test added in the following patch (KASAN: slab-out-of-bounds). Fixes: 14bf62cde7942 ("HID: add driver for Roccat Kone gaming mouse") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: nintendo: Fix imu_timestamp_us double increment per report

2026-09-14T11:31:44+00:00

[ Upstream commit 1f9b25d3fb65b9384dec16d9db13a3e71abd9145 ] Previously, the imu_timestamp_us variable was incremented twice per report, causing it to advance by two times the desired amount. This resulted in incorrect jumps in IMU timestamps reported using MSC_TIMESTAMP, so userspace applications saw corrupted timing on functions such as gyroscope-based aim and motion controls. This is fixed by removing the redundant increment at the start of the report handling so the remaining can account for the full report interval. Fixes: 4ff5b10840a88 ("HID: nintendo: add IMU support") Signed-off-by: Christos Maragkos Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: core: quiesce input in hid_hw_stop() to prevent use-after-free

2026-09-14T11:31:44+00:00

[ Upstream commit a4bc41504690b7d7064931909874f5b98cd148b6 ] A driver's probe calls hid_device_io_start() to enable input delivery, then fails at a later initialization step and unwinds via hid_hw_stop(). The unwind frees struct hidraw via hidraw_disconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidraw_report_event(). syzbot reports the resulting use-after-free for the corsair-psu HID driver. Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hid_device_io_stop() before hid_hw_stop() in the probe error path ("hwmon: prevent packets from going to driver for probe", 2026-04-28). Auditing the tree shows 15 drivers call hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not: drivers calling hid_device_io_start() without a matching hid_device_io_stop() before hid_hw_stop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabyte_waterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c Roughly half of all callers of the API are exposed. Centralize the quiesce in hid_hw_stop() so callers do not have to remember the matching stop: if a driver has left hdev->io_started true on entry, call hid_device_io_stop() before hid_disconnect(). For the 7 drivers that already call hid_device_io_stop() correctly, hdev->io_started is false on entry, the guard short-circuits, and behavior is unchanged. No Fixes: tag because the affected drivers gained their hid_device_io_start() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit. Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858 Signed-off-by: Philipp Weber Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: wacom: validate report length in wacom_intuos_pro2_bt_irq

2026-09-14T11:31:02+00:00

commit a8e04f3f894ccb52cfcd7e60125a9f35da4a616d upstream. wacom_intuos_pro2_bt_irq() receives the wire report length in `len` but never consults it before parsing. After the report-id gate it unconditionally calls wacom_intuos_pro2_bt_pen() and then, selected by features.type, a fixed chain of sub-parsers, none of which receive `len`: wacom_intuos_pro2_bt_pen(wacom); if (type == INTUOSP2_BT || type == INTUOSP2S_BT) { wacom_intuos_pro2_bt_touch(wacom); wacom_intuos_pro2_bt_pad(wacom); wacom_intuos_pro2_bt_battery(wacom); } else { wacom_intuos_gen3_bt_pad(wacom); wacom_intuos_gen3_bt_battery(wacom); } Each sub-parser dereferences wacom->data at fixed offsets. The furthest byte touched on each branch is: INTUOSP2_BT / INTUOSP2S_BT: wacom_intuos_pro2_bt_pad() reads data[285] (the touchring byte), so the report must be at least 286 bytes; INTUOSHT3_BT ("gen3"): wacom_intuos_gen3_bt_battery() reads data[45], so the report must be at least 46 bytes. features.type is selected from the VID/PID id_table entry and wacom_setup_device_quirks() force-registers the pen/pad/touch inputs for that type independent of the report descriptor, so a malicious or malfunctioning paired/spoofed Bluetooth peripheral can advertise that VID/PID and send an undersized report that still satisfies the data[0] == 0x80/0x81 gate. The driver then reads past the received report and forwards the bytes to userspace via evdev (MSC_SERIAL / ABS_MISC / ABS_WHEEL on the pen and pad input nodes), an out-of-bounds read with a concrete userspace read-back channel, and a true out-of-bounds read on transports whose backing buffer is sized to the (small) report descriptor rather than a fixed-size staging buffer. This is the same class of bug commit 2f1763f62909 ("HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq") already hardened in the sibling wacom_intuos_bt_irq(), which guards each report id against its minimum length before parsing. Guard wacom_intuos_pro2_bt_irq() the same way: before parsing, reject reports shorter than the furthest offset the selected branch actually dereferences, warn, and bail out. Because the whole pen/touch/pad/ battery chain runs unconditionally per branch, a single up-front check against the maximum offset (286 bytes for INTUOSP2_BT/INTUOSP2S_BT, 46 bytes for the gen3 branch) bounds every sub-parser. Returning 0 on a short report also skips those calls for the same malformed report, which is the safe, conservative behavior. Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov Assisted-by: AuditCode-AI:2026.07 Acked-by: Jason Gerecke Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman