linux/drivers/hid, branch v6.15

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

2025-05-15T17:57:24Z

Pull HID fixes from Benjamin Tissoires: - fix a few potential memory leaks in the wacom driver (Qasim Ijaz) - AMD SFH fixes when there is only one SRA sensor (Mario Limonciello) - HID-BPF dispatch UAF fix that happens on removal of the Logitech DJ receiver (Rong Zhang) - various minor fixes and usual device ID additions * tag 'hid-for-linus-2025051501' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: bpf: abort dispatch if device destroyed HID: quirks: Add ADATA XPG alpha wireless mouse support HID: hid-steam: Remove the unused variable connected HID: amd_sfh: Avoid clearing reports for SRA sensor HID: amd_sfh: Fix SRA sensor when it's the only sensor HID: wacom: fix shift OOB in kfifo allocation for zero pktlen HID: uclogic: Add NULL check in uclogic_input_configured() HID: wacom: fix memory leak on size mismatch in wacom_wac_queue_flush() HID: wacom: handle kzalloc() allocation failure in wacom_wac_queue_flush() HID: thrustmaster: fix memory leak in thrustmaster_interrupts() HID: hid-appletb-kbd: Fix wrong date and kernel version in sysfs interface docs HID: bpf: fix BTN_STYLUS for the XP Pen ACK05 remote

HID: bpf: abort dispatch if device destroyed

2025-05-13T13:53:50Z

The current HID bpf implementation assumes no output report/request will go through it after hid_bpf_destroy_device() has been called. This leads to a bug that unplugging certain types of HID devices causes a cleaned- up SRCU to be accessed. The bug was previously a hidden failure until a recent x86 percpu change [1] made it access not-present pages. The bug will be triggered if the conditions below are met: A) a device under the driver has some LEDs on B) hid_ll_driver->request() is uninplemented (e.g., logitech-djreceiver) If condition A is met, hidinput_led_worker() is always scheduled *after* hid_bpf_destroy_device(). hid_destroy_device ` hid_bpf_destroy_device ` cleanup_srcu_struct(&hdev->bpf.srcu) ` hid_remove_device ` ... ` led_classdev_unregister ` led_trigger_set(led_cdev, NULL) ` led_set_brightness(led_cdev, LED_OFF) ` ... ` input_inject_event ` input_event_dispose ` hidinput_input_event ` schedule_work(&hid->led_work) [hidinput_led_worker] This is fine when condition B is not met, where hidinput_led_worker() calls hid_ll_driver->request(). This is the case for most HID drivers, which implement it or use the generic one from usbhid. The driver itself or an underlying driver will then abort processing the request. Otherwise, hidinput_led_worker() tries hid_hw_output_report() and leads to the bug. hidinput_led_worker ` hid_hw_output_report ` dispatch_hid_bpf_output_report ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) The bug has existed since the introduction [2] of dispatch_hid_bpf_output_report(). However, the same bug also exists in dispatch_hid_bpf_raw_requests(), and I've reproduced (no visible effect because of the lack of [1], but confirmed bpf.destroyed == 1) the bug against the commit (i.e., the Fixes:) introducing the function. This is because hidinput_led_worker() falls back to hid_hw_raw_request() when hid_ll_driver->output_report() is uninplemented (e.g., logitech- djreceiver). hidinput_led_worker ` hid_hw_output_report: -ENOSYS ` hid_hw_raw_request ` dispatch_hid_bpf_raw_requests ` srcu_read_lock(&hdev->bpf.srcu) ` srcu_read_unlock(&hdev->bpf.srcu, idx) Fix the issue by returning early in the two mentioned functions if hid_bpf has been marked as destroyed. Though dispatch_hid_bpf_device_event() handles input events, and there is no evidence that it may be called after the destruction, the same check, as a safety net, is also added to it to maintain the consistency among all dispatch functions. The impact of the bug on other architectures is unclear. Even if it acts as a hidden failure, this is still dangerous because it corrupts whatever is on the address calculated by SRCU. Thus, CC'ing the stable list. [1]: commit 9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets") [2]: commit 9286675a2aed ("HID: bpf: add HID-BPF hooks for hid_hw_output_report") Closes: https://lore.kernel.org/all/20250506145548.GGaBoi9Jzp3aeJizTR@fat_crate.local/ Fixes: 8bd0488b5ea5 ("HID: bpf: add HID-BPF hooks for hid_hw_raw_requests") Cc: stable@vger.kernel.org Signed-off-by: Rong Zhang Tested-by: Petr Tesarik Link: https://patch.msgid.link/20250512152420.87441-1-i@rong.moe Signed-off-by: Benjamin Tissoires

HID: quirks: Add ADATA XPG alpha wireless mouse support

2025-04-24T11:01:57Z

This patch adds HID_QUIRK_ALWAYS_POLL for the ADATA XPG wireless gaming mouse (USB ID 125f:7505) and its USB dongle (USB ID 125f:7506). Without this quirk, the device does not generate input events properly. Signed-off-by: Milton Barrera Signed-off-by: Jiri Kosina

HID: hid-steam: Remove the unused variable connected

2025-04-24T10:52:11Z

Variable connected is not effectively used, so delete it. drivers/hid/hid-steam.c:1153:7: warning: variable ‘connected’ set but not used. Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=20462 Signed-off-by: Jiapeng Chong Signed-off-by: Jiri Kosina

HID: amd_sfh: Avoid clearing reports for SRA sensor

2025-04-24T10:17:55Z

SRA sensor doesn't allocate any memory for reports. Skip trying to clear memory for that sensor in cleanup path. Suggested-by: Basavaraj Natikar Signed-off-by: Mario Limonciello Acked-by: Basavaraj Natikar Signed-off-by: Jiri Kosina

HID: amd_sfh: Fix SRA sensor when it's the only sensor

2025-04-24T10:17:55Z

On systems that only have an SRA sensor connected to SFH the sensor doesn't get enabled due to a bad optimization condition of breaking the sensor walk loop. This optimization is unnecessary in the first place because if there is only one device then the loop only runs once. Drop the condition and explicitly mark sensor as enabled. Reported-by: Yijun Shen Tested-By: Yijun Shen Fixes: d1c444b47100d ("HID: amd_sfh: Add support to export device operating states") Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello Acked-by: Basavaraj Natikar Signed-off-by: Jiri Kosina

HID: wacom: fix shift OOB in kfifo allocation for zero pktlen

2025-04-24T10:13:32Z

During wacom_parse_and_register() the code calls wacom_devm_kfifo_alloc to allocate a fifo. During this operation it passes kfifo_alloc a fifo_size of 0. Kfifo attempts to round the size passed to it to the next power of 2 via roundup_pow_of_two (queue-type data structures do this to maintain efficiency of operations). However during this phase a problem arises when the roundup_pow_of_two() function utilises a shift exponent of fls_long(n-1), where n is the fifo_size. Since n is 0 in this case and n is also an unsigned long, doing n-1 causes unsigned integer wrap-around to occur making the fifo_size 4294967295. So the code effectively does fls_long(4294967295) which results in 64. Returning back to roundup_pow_of_two(), the code utilises a shift exponent of 64. When a shift exponent of 64 is used on a 64-bit type such as 1UL it results in a shift-out-of-bounds. The root cause of the issue seems to stem from insufficient validation of wacom_compute_pktlen(), since in this case the fifo_size comes from wacom_wac->features.pktlen. During wacom_parse_and_register() the wacom_compute_pktlen() function sets the pktlen as 0. To fix this, we should handle cases where wacom_compute_pktlen() results in 0. Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=d5204cbbdd921f1f7cad Fixes: 5e013ad20689 ("HID: wacom: Remove static WACOM_PKGLEN_MAX limit") Tested-by: Qasim Ijaz Reviewed-by: Jason Gerecke Cc: stable@vger.kernel.org Signed-off-by: Qasim Ijaz Signed-off-by: Jiri Kosina

HID: uclogic: Add NULL check in uclogic_input_configured()

2025-04-24T10:12:16Z

devm_kasprintf() returns NULL when memory allocation fails. Currently, uclogic_input_configured() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: dd613a4e45f8 ("HID: uclogic: Correct devm device reference for hidinput input_dev name") Signed-off-by: Henry Martin Signed-off-by: Jiri Kosina

HID: wacom: fix memory leak on size mismatch in wacom_wac_queue_flush()

2025-04-24T09:54:34Z

In wacom_wac_queue_flush() the code allocates zero initialised buffer which it uses as a storage buffer for copying data from a fifo via kfifo_out(). The kfifo_out() function returns the number of elements it has copied. The code checks if the number of copied elements does not equal the size of the fifo record, if it does not it simply skips the entry and continues to the next iteration. However it does not release the storage buffer leading to a memory leak. Fix the memory leak by freeing the buffer on size mismatch. Fixes: 5e013ad20689 ("HID: wacom: Remove static WACOM_PKGLEN_MAX limit") Reviewed-by: Jason Gerecke Signed-off-by: Qasim Ijaz Signed-off-by: Jiri Kosina

HID: wacom: handle kzalloc() allocation failure in wacom_wac_queue_flush()

2025-04-24T09:53:35Z

During wacom_wac_queue_flush() the code calls kzalloc() to allocate a zero initialised buffer which it uses as a storage buffer to get data from the fifo via kfifo_out(). However it does not check kzalloc() for allocation failure which returns NULL and could potentially lead to a NULL deref. Fix this by checking for kzalloc() failure and skipping the current entry if allocation failure occurs. Fixes: 5e013ad20689 ("HID: wacom: Remove static WACOM_PKGLEN_MAX limit") Signed-off-by: Qasim Ijaz Reviewed-by: Jason Gerecke Signed-off-by: Jiri Kosina