CVE-2026-80918

In the Linux kernel, the following vulnerability has been resolved:

HID: core: fix number/pointer type confusion on long items

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.