Re: [PATCH] HID: core: fix number/pointer type confusion on long items

Jiri Kosina <[email protected]>
Newsgroups gmane.linux.kernel.input,gmane.linux.kernel,gmane.linux.kernel.stable
Message-ID <[email protected]>
On Fri, 3 Jul 2026, Jann Horn wrote:

> When fetch_item() is called by hid_scan_report() on an item with
> HID_ITEM_TAG_LONG, it stores a pointer to the item data in
> item->data.longdata instead of storing a value directly in
> item->data.{u8/u16/u32}.
> 
> When item_udata() or item_sdata() encounters such an item, it incorrectly
> assumes that the item is in short format, and therefore returns the lower
> part of a kernel pointer reinterpreted as a number.
> 
> When a HID device is connected whose descriptor contains a
> HID_GLOBAL_ITEM_TAG_REPORT_SIZE encoded in long format with size=4, this
> causes the lower half of a kernel pointer to be printed into dmesg as a
> number, like this:
> 
>     hid (null): invalid report_size 107953555
> 
> To fix it, let item_udata() and item_sdata() verify that the item is in
> short format.
> 
> Note that this bug only affects hid_scan_report(), while the main parsing
> pass hid_parse_collections() will always bail out when encountering a long
> item.
> 
> Sidenote: There are currently no users of data.longdata; maybe we should
> just remove any parsing of long-format descriptors as a follow-up.
> 
> Fixes: 3dc8fc083dbf ("HID: Use hid_parser for pre-scanning the report descriptors")
> Cc: [email protected]
> Signed-off-by: Jann Horn <[email protected]>

Applied, thanks Jann.

-- 
Jiri Kosina
SUSE Labs
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.