mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* 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®