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

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®