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

HID: fix an error code in hid_check_device_match()

2026-09-14T11:19:19+00:00

[ Upstream commit 89e756e3cc8d9c1ebc0f2b2f6912227073d93118 ] The hid_check_device_match() returns true if we find a match and false if we don't. But here it returns -ENODEV which becomes true instead of false. Fixes: 207733f92661 ("HID: split apart hid_device_probe to make logic more apparent") Signed-off-by: Dan Carpenter Reviewed-by: Benjamin Tissoires Reviewed-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: lg4ff: validate report length before fixed offsets

2026-09-14T11:19:07+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: Fix "(null)" output when reading report descriptor fails

2026-09-14T11:19:07+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: i2c-hid: Switch i2c_hid_parse() to goto style error handling

2026-09-14T11:19:07+00:00

[ Upstream commit aa69d6974185e9f7a552ba982540a38e34f69690 ] Switch i2c_hid_parse() to goto style error handling. This is a preparation patch for removing the need for I2C_HID_QUIRK_NO_IRQ_AFTER_RESET by making i2c-hid behave more like Windows. Note this changes the descriptor read error path to propagate the actual i2c_hid_read_register() error code (which is always negative) instead of hardcoding a -EIO return. Reviewed-by: Douglas Anderson Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Stable-dep-of: 8da0f0951dee ("HID: i2c-hid: Fix "(null)" output when reading report descriptor fails") Signed-off-by: Sasha Levin

HID: synchronize input before cleaning up a failed probe

2026-09-14T11:19:07+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: ensure timely release of driver-allocated resources

2026-09-14T11:19:07+00:00

[ Upstream commit 62c68e7cee332e08e625af3bca3318814086490d ] More and more drivers rely on devres to manage their resources, however if bus' probe() and release() methods are not trivial and control some of resources as well (for example enable or disable clocks, or attach device to a power domain), we need to make sure that driver-allocated resources are released immediately after driver's remove() method returns, and not postponed until driver core gets around to releasing resources. In case of HID we should not try to close the report and release associated memory until after all devres callbacks are executed. To fix that we open a new devres group before calling driver's probe() and explicitly release it when we return from driver's remove(). This is similar to what we did for I2C bus in commit 5b5475826c52 ("i2c: ensure timely release of driver-allocated resources"). It is tempting to try and move this into driver core, but actually doing so is challenging, we need to split bus' remove() method into pre- and post-remove methods, which would make the logic even less clear. Reported-by: Stephen Boyd Link: https://lore.kernel.org/r/20230505232417.1377393-1-swboyd@chromium.org Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Stable-dep-of: 207853d46f7e ("HID: synchronize input before cleaning up a failed probe") Signed-off-by: Sasha Levin

HID: split apart hid_device_probe to make logic more apparent

2026-09-14T11:19:07+00:00

[ Upstream commit 207733f9266194b3cd90ddae723a1f82eb64030b ] hid_device_probe() has a complex flow and locks and unlocks a mutex. Move the most of the logic into __hid_device_probe() and hid_check_device_match() and leave the locking in hid_device_probe() which makes the code more clear. Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Stable-dep-of: 207853d46f7e ("HID: synchronize input before cleaning up a failed probe") Signed-off-by: Sasha Levin

HID: roccat: bound device-supplied profile index

2026-09-14T11:18:53+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: core: quiesce input in hid_hw_stop() to prevent use-after-free

2026-09-14T11:18:53+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:18:46+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