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

HID: quirks: Add ADATA XPG alpha wireless mouse support

2025-06-04T12:45:09+00:00

[ Upstream commit fa9fdeea1b7d6440c22efa6d59a769eae8bc89f1 ]

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 
Signed-off-by: Sasha Levin

HID: amd_sfh: Avoid clearing reports for SRA sensor

2025-06-04T12:45:09+00:00

[ Upstream commit f32e8c8095490152b5bc5f467d5034387a4bbd1b ]

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 
Signed-off-by: Sasha Levin

HID: Kconfig: Add LEDS_CLASS_MULTICOLOR dependency to HID_LOGITECH

2025-05-29T09:13:49+00:00

[ Upstream commit 4465f4fa21e0e54c10896db3ed49dbd5a9aad3fd ]

The test bot found an issue with building hid-lg-g15.

All errors (new ones prefixed by >>):

   powerpc-linux-ld: drivers/hid/hid-lg-g15.o: in function `lg_g510_kbd_led_write':
>> drivers/hid/hid-lg-g15.c:241:(.text+0x768): undefined reference to `led_mc_calc_color_components'
   powerpc-linux-ld: drivers/hid/hid-lg-g15.o: in function `lg_g15_register_led':
>> drivers/hid/hid-lg-g15.c:686:(.text+0xa9c): undefined reference to `devm_led_classdev_multicolor_register_ext'

Since multicolor LED APIs manage the keyboard backlight settings of
hid-lg-g15, the LEDS_CLASS_MULTICOLOR dependency was added to
HID_LOGITECH.

Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202502110032.VZ0J024X-lkp@intel.com/
Fixes: a3a064146c50 ("HID: hid-lg-g15: Use standard multicolor LED API")
Signed-off-by: Kate Hsuan 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: usbkbd: Fix the bit shift number for LED_KANA

2025-05-29T09:13:41+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: amd_sfh: Fix SRA sensor when it's the only sensor

2025-05-22T12:31:48+00:00

commit 0cc2effbc8f522af6b9d871cd27678e6aed9d56c upstream.

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 
Signed-off-by: Greg Kroah-Hartman

HID: bpf: abort dispatch if device destroyed

2025-05-22T12:31:48+00:00

commit 578e1b96fad7402ff7e9c7648c8f1ad0225147c8 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

HID: uclogic: Add NULL check in uclogic_input_configured()

2025-05-22T12:31:42+00:00

[ Upstream commit bd07f751208ba190f9b0db5e5b7f35d5bb4a8a1e ]

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 
Signed-off-by: Sasha Levin

HID: thrustmaster: fix memory leak in thrustmaster_interrupts()

2025-05-22T12:31:41+00:00

[ Upstream commit 09d546303b370113323bfff456c4e8cff8756005 ]

In thrustmaster_interrupts(), the allocated send_buf is not
freed if the usb_check_int_endpoints() check fails, leading
to a memory leak.

Fix this by ensuring send_buf is freed before returning in
the error path.

Fixes: 50420d7c79c3 ("HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check")
Signed-off-by: Qasim Ijaz 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: pidff: Fix set_device_control()

2025-04-20T08:22:47+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:22:46+00:00

[ Upstream commit f98ecedbeca34a8df1460c3a03cce32639c99a9d ]

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