kernel/linux.git/drivers/hid/bpf, branch v6.18.21

HID: bpf: prevent buffer overflow in hid_hw_request

2026-03-25T10:10:30+00:00

commit 2b658c1c442ec1cd9eec5ead98d68662c40fe645 upstream. right now the returned value is considered to be always valid. However, when playing with HID-BPF, the return value can be arbitrary big, because it's the return value of dispatch_hid_bpf_raw_requests(), which calls the struct_ops and we have no guarantees that the value makes sense. Fixes: 8bd0488b5ea5 ("HID: bpf: add HID-BPF hooks for hid_hw_raw_requests") Cc: stable@vger.kernel.org Acked-by: Jiri Kosina Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman

HID: bpf: abort dispatch if device destroyed

2025-05-13T13:53:50+00:00

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: bpf: fix BTN_STYLUS for the XP Pen ACK05 remote

2025-04-24T09:36:53+00:00

Usage_Dig_BarrelSwitch was applied in the UsagePage_Button which incorrectly mapped to BTN_TOOL_PENCIL Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/193 Fixes: 834da375 ("bpf: add a v6.11+ compatible BPF fixup for the XPPen ACK05 remote") Link: https://patchwork.kernel.org/project/linux-input/patch/20250207-bpf-import-2025-02-07-v1-7-6048fdd5a206@kernel.org/ Signed-off-by: Peter Hutterer Signed-off-by: Jiri Kosina

HID: bpf: add a v6.11+ compatible BPF fixup for the XPPen ACK05 remote

2025-02-24T08:25:34+00:00

With v6.11+, we can actually call hid_hw_output_report() and put the device into raw mode, thus getting accurate events without being messed up. Technically we could do the same on v6.10, but given that wayland, gnome and KDE are still not capable of handling the dial, and that v6.10 is EOL, we can safely save a little bit of compilation by only allowing v6.11+. We can easily export the battery information to userspace by adding a dedicated report. However, we need to cheat on the kernel to force it not to query the battery by making the physical collection a stylus. The kernel will then only rely on the events it gets from the device. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/133 Acked-by: Jiri Kosina Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-7-6048fdd5a206@kernel.org Signed-off-by: Benjamin Tissoires

HID: bpf: new hid_bpf_async.h common header

2025-02-24T08:25:34+00:00

The purpose is to simplify the use of bpf_wq to defer blocking operations in a sleepable context. Compared to a more "classic" async approach, there is no sync mechanism to wait for the async to finish. The "simple" API is the following: ``` static int HID_BPF_ASYNC(async_fun)(struct hid_bpf_ctx *hctx) { bpf_printk("%s", __fun__); return 0; } SEC("syscall") int probe(struct hid_bpf_probe_args *ctx) { ctx->retval = HID_BPF_ASYNC_INIT(async_fun); return 0; } SEC(HID_BPF_DEVICE_EVENT) int BPF_PROG(event_handler, struct hid_bpf_ctx *hctx) { /* async_fun() can be called now, it's not a sleepable * function in this example */ async_fun(hctx); /* but we can also delay the call by 10 ms */ HID_BPF_ASYNC_DELAYED_CALL(async_fun, hctx, 10); return 0; } HID_BPF_OPS(xppen_ack05_remote) = { .hid_device_event = (void *)event_handler, }; ``` Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/133 Acked-by: Jiri Kosina Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-6-6048fdd5a206@kernel.org Signed-off-by: Benjamin Tissoires

HID: bpf: import new kfunc from v6.10 & v6.11

2025-02-24T08:25:34+00:00

These kfunc are all in v6.10 except for the hid_bpf_try_input_report() which will be in v6.11. Import their definition once now so we can make use of it. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/114 Acked-by: Jiri Kosina Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-5-6048fdd5a206@kernel.org Signed-off-by: Benjamin Tissoires

HID: bpf: add support for the XP-Pen Artist Pro 19 (gen2)

2025-02-24T08:25:34+00:00

The device behaves the same than the 16" and 14" models, so let's just add support for it too. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/145 Acked-by: Jiri Kosina Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-4-6048fdd5a206@kernel.org Signed-off-by: Benjamin Tissoires

HID: bpf: Added updated Kamvas Pro 19 descriptor

2025-02-24T08:25:34+00:00

This adds an updated HID descriptor for the Huion Kamvas Pro 19 that is present on newer firmware revisions, while also trying to keep compat with the older versions. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/164 Signed-off-by: Aki Van Ness Acked-by: Jiri Kosina Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-3-6048fdd5a206@kernel.org Signed-off-by: Benjamin Tissoires

HID: bpf: Suppress bogus F13 trigger on Sirius keyboard full fan shortcut

2025-02-24T08:25:33+00:00

The TUXEDO Sirius 16 Gen1 and the TUXEDO Sirius 16 Gen2 Notebooks have an additional "fan" key next to F12. Pressing it alone sends a F14 key press which can be bound by user space. Pressing it while holding the FN key triggers two things: - The EC firmware locks the fan speed of the internal fans at 100% - F13 key press is registered which by default is already bound in xkb and desktop environments (e.g. in KDE Plasma it launches system settings) To avoid this unexpected double duty of the FN shortcut, this bpf program suppresses the F13 key press. Signed-off-by: Werner Sembach Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/166 Acked-by: Jiri Kosina Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-2-6048fdd5a206@kernel.org Signed-off-by: Benjamin Tissoires

HID: bpf: Add support for the default firmware mode of the Huion K20

2025-02-24T08:25:33+00:00

This re-uses the same HID report descriptor that we also use for the tablet mode after switching the device. The keys send uniquely identifyable shortcuts so we can map those to buttons. However the dial and the button inside the dial send events on a different hidraw node and they are unreliable (e.g. the button does not get released reliably). So they're ignored in this patch, it's not worth the effort getting those to work correctly. Signed-off-by: Peter Hutterer Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/158 Acked-by: Jiri Kosina Link: https://patch.msgid.link/20250207-bpf-import-2025-02-07-v1-1-6048fdd5a206@kernel.org Signed-off-by: Benjamin Tissoires