CVE-2026-80918

What it actually does

The flaw is a type confusion in HID descriptor parsing where item_udata() and item_sdata() treat a long-format HID_ITEM_TAG_LONG item's kernel pointer (stored in item->data.longdata) as a short-format integer, returning the lower half of that pointer value instead of the intended data.

Why it matters to the business

A locally connected or emulated malicious HID device can trigger a kernel pointer disclosure into system logs, giving attackers a building block for more reliable kernel exploits on affected Linux systems.

How an attack unfolds

An attacker crafts a USB or Bluetooth HID device whose report descriptor encodes a REPORT_SIZE item using the long format with size=4. When the kernel calls hid_scan_report() on attachment, the pointer reinterpretation leaks the lower 32 bits of a kernel address into dmesg as an "invalid report_size" value; the main hid_parse_collections() path rejects long items so the device is only partially processed.

How to fix it

Apply the upstream fix that adds short-format checks inside item_udata() and item_sdata(); rebuild and reboot with a patched kernel. Until patches are available, restrict untrusted HID devices via USBGuard or physical port controls and consider disabling HID long-item parsing if a downstream patch removes the code path.

How to confirm the fix worked

After patching, connect a test HID device containing a long-format REPORT_SIZE item and confirm the kernel log no longer emits an "invalid report_size" message containing a large hexadecimal-looking number; also verify that hid_scan_report() no longer dereferences long-item data as short integers.

Typical attack path

1. attacker presents a USB/Bluetooth HID device with a long-format HID_GLOBAL_ITEM_TAG_REPORT_SIZE descriptor
2. kernel invokes hid_scan_report() which calls fetch_item() and stores the long item pointer
3. item_udata()/item_sdata() misinterprets the pointer as an integer and emits the value to the kernel log
4. attacker reads dmesg or /var/log/kern.log to obtain a kernel address for subsequent exploitation

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for the exact phrase "invalid report_size" followed by a decimal number that resembles a truncated kernel pointer; correlate with recent USB or Bluetooth HID device connection events.

• invalid report_size [0-9]{8,}
• hid (null): invalid report_size

What your security team should do

• Prioritize kernel updates on all Linux endpoints that accept arbitrary HID devices
• Add kernel log monitoring rules for the string "invalid report_size" followed by an anomalous numeric value
• Enforce USB device allow-listing for high-risk workstations until patches are deployed