Re: HID: intended semantics around report buffer length?

[Benjamin Tissoires]

Hi Jarn,

On Sep 21 2026, Jann Horn wrote:
> Hi!
> 
> I've noticed that some HID drivers seem to assume that HID events come
> in buffers of at least HID_MIN_BUFFER_SIZE bytes for historical
> reasons. As a random example, elo_raw_event() can pass the supplied
> buffer to elo_process_data(), which can access data[1..7] without
> checking the size parameter.
> 
> However, HID-BPF exposes the kfuncs hid_bpf_input_report() and
> hid_bpf_try_input_report() which appear to allow BPF code to pass any
> buffer with size >=1 into this codepath.
> 
> What is the intended API contract for buffers passed into
> hid_driver::raw_event? Are HID drivers allowed to assume that these
> buffers are always >=HID_MIN_BUFFER_SIZE bytes (in which case I think
> HID-BPF probably has a bug), or are all HID drivers without explicit
> size checks buggy?

I think it's safer to not assume anything regarding the size.

I just double checked hid-elo.c and it does call in its probe
`hid_is_usb(hdev)` so we guarantee that the transport layer is indeed
usbhid, and so we know that .raw_event() will be called with
HID_MIN_BUFFER_SIZE at least.

The thing is uhid is not guaranteeing HID_MIN_BUFFER_SIZE, and it has
been around for a while, so no, we can't assume size is at least
HID_MIN_BUFFER_SIZE, unless in conjonctions with some conditions on the
driver.

Cheers,
Benjamin