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

HID: core: clamp report_size in s32ton() to avoid undefined shift

2026-04-22T11:18:57+00:00

commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream.

s32ton() shifts by n-1 where n is the field's report_size, a value that
comes directly from a HID device.  The HID parser bounds report_size
only to <= 256, so a broken HID device can supply a report descriptor
with a wide field that triggers shift exponents up to 256 on a 32-bit
type when an output report is built via hid_output_field() or
hid_set_field().

Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in
hid_report_raw_event") added the same n > 32 clamp to the function
snto32(), but s32ton() was never given the same fix as I guess syzbot
hadn't figured out how to fuzz a device the same way.

Fix this up by just clamping the max value of n, just like snto32()
does.

Cc: stable 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: alps: fix NULL pointer dereference in alps_raw_event()

2026-04-22T11:18:57+00:00

commit 1badfc4319224820d5d890f8eab6aa52e4e83339 upstream.

Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event
callbacks missing them") attempted to fix up the HID drivers that had
missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:
Fix potential NULL dereference at raw event handle"), but the alps
driver was missed.

Fix this up by properly checking in the hid-alps driver that it had been
claimed correctly before attempting to process the raw event.

Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
Cc: stable 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: Masaki Ota 
Cc: linux-input@vger.kernel.org
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: amd_sfh: don't log error when device discovery fails with -EOPNOTSUPP

2026-04-22T11:18:51+00:00

[ Upstream commit 743677a8cb30b09f16a7f167f497c2c927891b5a ]

When sensor discovery fails on systems without AMD SFH sensors, the
code already emits a warning via dev_warn() in amd_sfh_hid_client_init().
The subsequent dev_err() in sfh_init_work() for the same -EOPNOTSUPP
return value is redundant and causes unnecessary alarm.

Suppress the dev_err() for -EOPNOTSUPP to avoid confusing users who
have no AMD SFH sensors.

Fixes: 2105e8e00da4 ("HID: amd_sfh: Improve boot time when SFH is available")
Reported-by: Casey Croy 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221099
Signed-off-by: Maximilian Pezzullo 
Acked-by: Basavaraj Natikar 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: roccat: fix use-after-free in roccat_report_event

2026-04-22T11:18:49+00:00

[ Upstream commit d802d848308b35220f21a8025352f0c0aba15c12 ]

roccat_report_event() iterates over the device->readers list without
holding the readers_lock. This allows a concurrent roccat_release() to
remove and free a reader while it's still being accessed, leading to a
use-after-free.

Protect the readers list traversal with the readers_lock mutex.

Signed-off-by: Benoît Sevens 
Reviewed-by: Silvan Jegen 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: quirks: add HID_QUIRK_ALWAYS_POLL for 8BitDo Pro 3

2026-04-22T11:18:49+00:00

[ Upstream commit 532743944324a873bbaf8620fcabcd0e69e30c36 ]

According to a mailing list report [1], this controller's predecessor
has the same issue. However, it uses the xpad driver instead of HID, so
this quirk wouldn't apply.

[1]: https://lore.kernel.org/linux-input/unufo3$det$1@ciao.gmane.io/

Signed-off-by: leo vriska 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: multitouch: Check to ensure report responses match the request

2026-04-11T12:24:29+00:00

[ Upstream commit e716edafedad4952fe3a4a273d2e039a84e8681a ]

It is possible for a malicious (or clumsy) device to respond to a
specific report's feature request using a completely different report
ID.  This can cause confusion in the HID core resulting in nasty
side-effects such as OOB writes.

Add a check to ensure that the report ID in the response, matches the
one that was requested.  If it doesn't, omit reporting the raw event and
return early.

Signed-off-by: Lee Jones 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Sasha Levin

HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure

2026-04-11T12:24:29+00:00

[ Upstream commit f7a4c78bfeb320299c1b641500fe7761eadbd101 ]

Presently, if the force feedback initialisation fails when probing the
Logitech G920 Driving Force Racing Wheel for Xbox One, an error number
will be returned and propagated before the userspace infrastructure
(sysfs and /dev/input) has been torn down.  If userspace ignores the
errors and continues to use its references to these dangling entities, a
UAF will promptly follow.

We have 2 options; continue to return the error, but ensure that all of
the infrastructure is torn down accordingly or continue to treat this
condition as a warning by emitting the message but returning success.
It is thought that the original author's intention was to emit the
warning but keep the device functional, less the force feedback feature,
so let's go with that.

Signed-off-by: Lee Jones 
Reviewed-by: Günther Noack 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Sasha Levin

HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq

2026-04-11T12:24:29+00:00

[ Upstream commit 2f1763f62909ccb6386ac50350fa0abbf5bb16a9 ]

The wacom_intuos_bt_irq() function processes Bluetooth HID reports
without sufficient bounds checking. A maliciously crafted short report
can trigger an out-of-bounds read when copying data into the wacom
structure.

Specifically, report 0x03 requires at least 22 bytes to safely read
the processed data and battery status, while report 0x04 (which
falls through to 0x03) requires 32 bytes.

Add explicit length checks for these report IDs and log a warning if
a short report is received.

Signed-off-by: Benoît Sevens 
Reviewed-by: Jason Gerecke 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: logitech-hidpp: Enable MX Master 4 over bluetooth

2026-04-11T12:24:28+00:00

[ Upstream commit 70031e70ca15ede6a39db4d978e53a6cc720d454 ]

The Logitech MX Master 4 can be connected over bluetooth or through a
Logitech Bolt receiver. This change adds support for non-standard HID
features, such as high resolution scrolling when the mouse is connected
over bluetooth.
Because no Logitech Bolt receiver driver exists yet those features
won't be available when the mouse is connected through the receiver.

Signed-off-by: Adrian Freund 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: apple: avoid memory leak in apple_report_fixup()

2026-04-02T11:09:28+00:00

[ Upstream commit 239c15116d80f67d32f00acc34575f1a6b699613 ]

The apple_report_fixup() function was returning a
newly kmemdup()-allocated buffer, but never freeing it.

The caller of report_fixup() does not take ownership of the returned
pointer, but it *is* permitted to return a sub-portion of the input
rdesc, whose lifetime is managed by the caller.

Assisted-by: Gemini-CLI:Google Gemini 3
Signed-off-by: Günther Noack 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Sasha Levin