kernel/linux.git/drivers/hid/usbhid, branch v7.0.10

HID: core: introduce hid_safe_input_report()

2026-05-23T11:09:38+00:00

[ Upstream commit 206342541fc887ae919774a43942dc883161fece ] hid_input_report() is used in too many places to have a commit that doesn't cross subsystem borders. Instead of changing the API, introduce a new one when things matters in the transport layers: - usbhid - i2chid This effectively revert to the old behavior for those two transport layers. Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: usbhid: fix deadlock in hid_post_reset()

2026-05-23T11:09:06+00:00

[ Upstream commit 8df2c1b47ee3cd50fd454f75c7a7e2ae8a6adf72 ] You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them. Fixes: dc3c78e434690 ("HID: usbhid: Check HID report descriptor contents after device reset") Signed-off-by: Oliver Neukum Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: pidff: Fix integer overflow in pidff_rescale

2026-05-17T15:16:22+00:00

commit 48d1677779ad6816978ad4a4f7588aec5ec960fe upstream. Rescaling values close to the max (U16_MAX) temporarily creates values that exceed the s32 range. This caused value overflow in case when, for example, a periodic effect phase was higer than 180 degrees. In turn, rescale function could return values outised of the logical range of the HID field. Fix by using 64 bit signed integer to store the value during calculation but still return only 32 bit integer. Closes: https://github.com/JacKeTUs/universal-pidff/issues/116 Fixes: 224ee88fe395 ("Input: add force feedback driver for PID devices") Cc: stable@vger.kernel.org Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

Merge tag 'hid-for-linus-2026030601' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid

2026-03-06T18:00:58+00:00

Pull HID fixes from Benjamin Tissoires: - fix a few memory leaks (Günther Noack) - fix potential kernel crashes in cmedia, creative-sb0540 and zydacron (Greg Kroah-Hartman) - fix NULL pointer dereference in pidff (Tomasz Pakuła) - fix battery reporting for Apple Magic Trackpad 2 (Julius Lehmann) - mcp2221 proper handling of failed read operation (Romain Sioen) - various device quirks / device ID additions * tag 'hid-for-linus-2026030601' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: mcp2221: cancel last I2C command on read error HID: asus: add xg mobile 2023 external hardware support HID: multitouch: Keep latency normal on deactivate for reactivation gesture HID: apple: Add EPOMAKER TH87 to the non-apple keyboards list HID: intel-ish-hid: ipc: Add Nova Lake-H/S PCI device IDs selftests: hid: tests: test_wacom_generic: add tests for display devices and opaque devices HID: multitouch: new class MT_CLS_EGALAX_P80H84 HID: magicmouse: fix battery reporting for Apple Magic Trackpad 2 HID: pidff: Fix condition effect bit clearing HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them HID: asus: avoid memory leak in asus_report_fixup() HID: magicmouse: avoid memory leak in magicmouse_report_fixup() HID: apple: avoid memory leak in apple_report_fixup() HID: Document memory allocation properties of report_fixup()

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

HID: pidff: Fix condition effect bit clearing

2026-02-21T09:47:12+00:00

As reported by MPDarkGuy on discord, NULL pointer dereferences were happening because not all the conditional effects bits were cleared. Properly clear all conditional effect bits from ffbit Fixes: 7f3d7bc0df4b ("HID: pidff: Better quirk assigment when searching for fields") Cc: stable@vger.kernel.org # 6.18.x Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

HID: pidff: Do not set out of range trigger button

2026-01-10T09:06:48+00:00

Some games (mainly observed with Kylotonn's WRC Serises) set trigger button to a random value, or always the same one, out of range. I observed 307 and other values but, for example, my Moza R9 only exposes 128 buttons AND it's trigger button field is 8-bit. This causes errors to appear in dmesg. Only set the trigger button and trigger interval in the trigger button is in range of the field. Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina

HID: usbhid: paper over wrong bNumDescriptor field

2025-12-19T10:50:19+00:00

Some faulty devices (ZWO EFWmini) have a wrong optional HID class descriptor count compared to the provided length. Given that we plainly ignore those optional descriptor, we can attempt to fix the provided number so we do not lock out those devices. Signed-off-by: Benjamin Tissoires

HID: pidff: Fix needs_playback check

2025-11-18T17:04:28+00:00

A small bug made it's way here when rewriting code to Linux quality. Currently, if an effect is not infinite and a program requests it's playback with the same number of loops, the play command won't be fired and if an effect is infinite, the spam will continue. We want every playback update for non-infinite effects and only some for infinite (detecting when a program requests stop with 0 which will be different than previous value which is usually 1 or 255). Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina