linux-stable.git/drivers/hid, branch v6.18.26

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

2026-04-22T11:22:25+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:22:25+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:22:18+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:22:15+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:22:15+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: Intel-thc-hid: Intel-quickspi: Add NVL Device IDs

2026-04-22T11:22:15+00:00

[ Upstream commit 48e91af0cbe942d50ef6257d850accdca1d01378 ]

Add Nova Lake THC QuickSPI device IDs to support list.

Signed-off-by: Even Xu 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: appletb-kbd: add .resume method in PM

2026-04-11T12:26:48+00:00

commit 1965445e13c09b79932ca8154977b4408cb9610c upstream.

Upon resuming from suspend, the Touch Bar driver was missing a resume
method in order to restore the original mode the Touch Bar was on before
suspending. It is the same as the reset_resume method.

Cc: stable@vger.kernel.org
Signed-off-by: Aditya Garg 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

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

2026-04-11T12:26:17+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: core: Mitigate potential OOB by removing bogus memset()

2026-04-11T12:26:17+00:00

[ Upstream commit 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c ]

The memset() in hid_report_raw_event() has the good intention of
clearing out bogus data by zeroing the area from the end of the incoming
data string to the assumed end of the buffer.  However, as we have
previously seen, doing so can easily result in OOB reads and writes in
the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the
memset() and simply return if the incoming event buffer size is not
large enough to fill the associated report.

Suggested-by Benjamin Tissoires 

Signed-off-by: Lee Jones 
[bentiss: changed the return value]
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:26:17+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