* HID: intended semantics around report buffer length?
@ 2026-09-21 17:24 Jann Horn
2026-09-22 6:38 ` Benjamin Tissoires
0 siblings, 1 reply; 2+ messages in thread
From: Jann Horn @ 2026-09-21 17:24 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input; +Cc: kernel list
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?
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: HID: intended semantics around report buffer length?
2026-09-21 17:24 HID: intended semantics around report buffer length? Jann Horn
@ 2026-09-22 6:38 ` Benjamin Tissoires
0 siblings, 0 replies; 2+ messages in thread
From: Benjamin Tissoires @ 2026-09-22 6:38 UTC (permalink / raw)
To: Jann Horn; +Cc: Jiri Kosina, linux-input, kernel list
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-09-22 6:38 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-21 17:24 HID: intended semantics around report buffer length? Jann Horn
2026-09-22 6:38 ` Benjamin Tissoires
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®