kernel/linux.git/drivers/hid/usbhid, branch v6.12.80

HID: usbhid: paper over wrong bNumDescriptor field

2026-01-23T10:18:42+00:00

commit f28beb69c51517aec7067dfb2074e7c751542384 upstream. 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 Cc: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman

HID: pidff: PERMISSIVE_CONTROL quirk autodetection

2025-11-13T20:34:13+00:00

[ Upstream commit c2dc9f0b368c08c34674311cf78407718d5715a7 ] Fixes force feedback for devices built with MMOS firmware and many more not yet detected devices. Update quirks mask debug message to always contain all 32 bits of data. Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: pidff: Use direction fix only for conditional effects

2025-11-13T20:34:13+00:00

[ Upstream commit f345a4798dab800159b09d088e7bdae0f16076c3 ] The already fixed bug in SDL only affected conditional effects. This should fix FFB in Forza Horizion 4/5 on Moza Devices as Forza Horizon flips the constant force direction instead of using negative magnitude values. Changing the direction in the effect directly in pidff_upload_effect() would affect it's value in further operations like comparing to the old effect and/or just reading the effect values in the user application. This, in turn, would lead to constant PID_SET_EFFECT spam as the effect direction would constantly not match the value that's set by the application. This way, it's still transparent to any software/API. Only affects conditional effects now so it's better for it to explicitly state that in the name. If any HW ever needs fixed direction for other effects, we'll add more quirks. Signed-off-by: Tomasz Pakuła Reviewed-by: Oleg Makarenko Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()

2025-06-19T13:32:34+00:00

commit fe7f7ac8e0c708446ff017453add769ffc15deed upstream. Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor. Update all references to member element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault. Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors. Reported-by: syzbot+c52569baf0c843f35495@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c52569baf0c843f35495 Fixes: f043bfc98c19 ("HID: usbhid: fix out-of-bounds bug") Cc: stable@vger.kernel.org Signed-off-by: Terry Junge Reviewed-by: Michael Kelley Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: usbkbd: Fix the bit shift number for LED_KANA

2025-05-29T09:03:04+00:00

[ Upstream commit d73a4bfa2881a6859b384b75a414c33d4898b055 ] Since "LED_KANA" was defined as "0x04", the shift number should be "4". Signed-off-by: junan Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: pidff: Fix set_device_control()

2025-04-20T08:15:31+00:00

[ Upstream commit e2fa0bdf08a70623f24ed52f2037a330999d9800 ] As the search for Device Control report is permissive, make sure the desired field was actually found, before trying to set it. Fix bitmask clearing as it was erronously using index instead of index - 1 (HID arrays index is 1-based). Add last two missing Device Control usages to the defined array. PID_PAUSE and PID_CONTINUE. Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: pidff: Fix 90 degrees direction name North -> East

2025-04-20T08:15:31+00:00

[ Upstream commit f98ecedbeca34a8df1460c3a03cce32639c99a9d ] Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: pidff: Compute INFINITE value instead of using hardcoded 0xffff

2025-04-20T08:15:31+00:00

[ Upstream commit 1a575044d516972a1d036d54c0180b9085e21dc6 ] As per USB PID standard: INFINITE - Referrers to the maximum value of a range. i.e. if in an 8 bit unsigned field the value of 255 would indicate INFINITE. Detecting 0xffff (U16_MAX) is still important as we MIGHT get this value as infinite from some native software as 0 was never actually defined in Linux' FF api as the infinite value. I'm working on it though. Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: pidff: Clamp effect playback LOOP_COUNT value

2025-04-20T08:15:31+00:00

[ Upstream commit 0c6673e3d17b258b8c5c7331d28bf6c49f25ed30 ] Ensures the loop count will never exceed the logical_maximum. Fixes implementation errors happening when applications use the max value of int32/DWORD as the effect iterations. This could be observed when running software both native and in wine. Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: pidff: Rename two functions to align them with naming convention

2025-04-20T08:15:31+00:00

[ Upstream commit bbeface1051142bcb0473fdcc89102ea5b31607d ] Driver uses "set" everywhere to indicate setting report values and requesting HID_REQ_SET_REPORT Signed-off-by: Tomasz Pakuła Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin