linux-stable.git/drivers/hid/bpf, branch linux-rolling-lts

HID: bpf: Fix hid_bpf_get_data() range check

2026-07-24T14:16:46+00:00

[ Upstream commit 2d044049421dd48212b28646a850749d4a2d57fa ]

hid_bpf_get_data() returns a pointer into the HID-BPF context data when
the caller-provided offset and size fit inside ctx->allocated_size.

The current check adds rdwr_buf_size and offset before comparing the
result against ctx->allocated_size. Since both values are unsigned, a
very large size can wrap the sum below ctx->allocated_size and make the
helper return a pointer even though the requested range is not contained
in the backing buffer.

Use check_add_overflow() to reject wrapped range ends before comparing
the requested range end against ctx->allocated_size.

Fixes: 658ee5a64fcf ("HID: bpf: allocate data memory for device_event BPF programs")
Signed-off-by: Yiyang Chen 
Signed-off-by: Benjamin Tissoires 
Signed-off-by: Sasha Levin

HID: pass the buffer size to hid_report_raw_event

2026-05-23T11:07:16+00:00

[ Upstream commit 2c85c61d1332e1e16f020d76951baf167dcb6f7a ]

commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
bogus memset()") enforced the provided data to be at least the size of
the declared buffer in the report descriptor to prevent a buffer
overflow. However, we can try to be smarter by providing both the buffer
size and the data size, meaning that hid_report_raw_event() can make
better decision whether we should plaining reject the buffer (buffer
overflow attempt) or if we can safely memset it to 0 and pass it to the
rest of the stack.

Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires 
Acked-by: Johan Hovold 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Kosina 
Stable-dep-of: 206342541fc8 ("HID: core: introduce hid_safe_input_report()")
Signed-off-by: Sasha Levin

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