kernel/linux.git/drivers/hid, branch v6.13.6

HID: hid-steam: Move hidraw input (un)registering to work

2025-02-21T13:11:16+00:00

[ Upstream commit 79504249d7e27cad4a3eeb9afc6386e418728ce0 ] Due to an interplay between locking in the input and hid transport subsystems, attempting to register or deregister the relevant input devices during the hidraw open/close events can lead to a lock ordering issue. Though this shouldn't cause a deadlock, this commit moves the input device manipulation to deferred work to sidestep the issue. Fixes: 385a4886778f6 ("HID: steam: remove input device when a hid client is running.") Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: hid-steam: Make sure rumble work is canceled on removal

2025-02-21T13:11:16+00:00

[ Upstream commit cc4f952427aaa44ecfd92542e10a65cce67bd6f4 ] When a force feedback command is sent from userspace, work is scheduled to pass this data to the controller without blocking userspace itself. However, in theory, this work might not be properly canceled if the controller is removed at the exact right time. This patch ensures the work is properly canceled when the device is removed. Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Stable-dep-of: 79504249d7e2 ("HID: hid-steam: Move hidraw input (un)registering to work") Signed-off-by: Sasha Levin

HID: hid-steam: Don't use cancel_delayed_work_sync in IRQ context

2025-02-21T13:10:44+00:00

[ Upstream commit b051ffa2aeb2a60e092387b6fb2af1ad42f51a3c ] Lockdep reported that, as steam_do_deck_input_event is called from steam_raw_event inside of an IRQ context, it can lead to issues if that IRQ occurs while the work to be cancelled is running. By using cancel_delayed_work, this issue can be avoided. The exact ordering of the work and the event processing is not super important, so this is safe. Fixes: cd438e57dd05 ("HID: hid-steam: Add gamepad-only mode switched to by holding options") Signed-off-by: Vicki Pfau Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: hid-thrustmaster: fix stack-out-of-bounds read in usb_check_int_endpoints()

2025-02-21T13:10:44+00:00

[ Upstream commit 0b43d98ff29be3144e86294486b1373b5df74c0e ] Syzbot[1] has detected a stack-out-of-bounds read of the ep_addr array from hid-thrustmaster driver. This array is passed to usb_check_int_endpoints function from usb.c core driver, which executes a for loop that iterates over the elements of the passed array. Not finding a null element at the end of the array, it tries to read the next, non-existent element, crashing the kernel. To fix this, a 0 element was added at the end of the array to break the for loop. [1] https://syzkaller.appspot.com/bug?extid=9c9179ac46169c56c1ad Reported-by: syzbot+9c9179ac46169c56c1ad@syzkaller.appspotmail.com Fixes: 50420d7c79c3 ("HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check") Signed-off-by: Túlio Fernandes Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: multitouch: Add NULL check in mt_input_configured

2025-02-21T13:10:43+00:00

[ Upstream commit 9b8e2220d3a052a690b1d1b23019673e612494c5 ] devm_kasprintf() can return a NULL pointer on failure,but this returned value in mt_input_configured() is not checked. Add NULL check in mt_input_configured(), to handle kernel NULL pointer dereference error. Fixes: 479439463529 ("HID: multitouch: Correct devm device reference for hidinput input_dev name") Signed-off-by: Charles Han Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: winwing: Add NULL check in winwing_init_led()

2025-02-21T13:10:43+00:00

[ Upstream commit 45ab5166a82d038c898985b0ad43ead69c1f9573 ] devm_kasprintf() can return a NULL pointer on failure,but this returned value in winwing_init_led() is not checked. Add NULL check in winwing_init_led(), to handle kernel NULL pointer dereference error. Fixes: 266c990debad ("HID: Add WinWing Orion2 throttle support") Signed-off-by: Charles Han Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin

HID: corsair-void: Add missing delayed work cancel for headset status

2025-02-21T13:10:41+00:00

commit 48e487b002891eb0aeaec704c9bed51f028deff1 upstream. The cancel_delayed_work_sync() call was missed, causing a use-after-free in corsair_void_remove(). Reported-by: yan kang Reported-by: yue sun Closes: https://lore.kernel.org/all/SY8P300MB042106286A2536707D2FB736A1E42@SY8P300MB0421.AUSP300.PROD.OUTLOOK.COM/ Closes: https://lore.kernel.org/all/SY8P300MB0421872E0AE934C9616FA61EA1E42@SY8P300MB0421.AUSP300.PROD.OUTLOOK.COM/ Fixes: 6ea2a6fd3872 ("HID: corsair-void: Add Corsair Void headset family driver") Cc: stable@vger.kernel.org Signed-off-by: Stuart Hayhurst Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: corsair-void: Initialise memory for psy_cfg

2025-02-21T13:10:41+00:00

commit c098363828f7006ef5c5121b673bc5e26571e6c8 upstream. power_supply_config psy_cfg was missing its initialiser, add it in. Fixes: 6ea2a6fd3872 ("HID: corsair-void: Add Corsair Void headset family driver") Cc: stable@vger.kernel.org Signed-off-by: Stuart Hayhurst Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: hid-sensor-hub: don't use stale platform-data on remove

2025-02-17T10:36:26+00:00

commit 8a5b38c3fd709e8acd2bfdedf66c25e6af759576 upstream. The hid-sensor-hub creates the individual device structs and transfers them to the created mfd platform-devices via the platform_data in the mfd_cell. Before e651a1da442a ("HID: hid-sensor-hub: Allow parallel synchronous reads") the sensor-hub was managing access centrally, with one "completion" in the hub's data structure, which needed to be finished on removal at the latest. The mentioned commit then moved this central management to each hid sensor device, resulting on a completion in each struct hid_sensor_hub_device. The remove procedure was adapted to go through all sensor devices and finish any pending "completion". What this didn't take into account was, platform_device_add_data() that is used by mfd_add{_hotplug}_devices() does a kmemdup on the submitted platform-data. So the data the platform-device gets is a copy of the original data, meaning that the device worked on a different completion than what sensor_hub_remove() currently wants to access. To fix that, use device_for_each_child() to go through each child-device similar to how mfd_remove_devices() unregisters the devices later and with that get the live platform_data to finalize the correct completion. Fixes: e651a1da442a ("HID: hid-sensor-hub: Allow parallel synchronous reads") Cc: stable@vger.kernel.org Signed-off-by: Heiko Stuebner Acked-by: Benjamin Tissoires Acked-by: Srinivas Pandruvada Acked-by: Jiri Kosina Link: https://lore.kernel.org/r/20241107114712.538976-2-heiko@sntech.de Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman

HID: hid-asus: Disable OOBE mode on the ProArt P16

2025-02-17T10:36:04+00:00

[ Upstream commit 53078a736fbc60e5d3a1e14f4cd4214003815026 ] The new ASUS ProArt 16" laptop series come with their keyboards stuck in an Out-Of-Box-Experience mode. While in this mode most functions will not work such as LED control or Fn key combos. The correct init sequence is now done to disable this OOBE. This patch addresses only the ProArt series so far and it is unknown if there may be others, in which case a new quirk may be required. Signed-off-by: Luke D. Jones Co-developed-by: Connor Belli Signed-off-by: Connor Belli Tested-by: Jan Schmidt Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin