CVE-2026-80918 in Linux
Summary
by MITRE • 09/09/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/09/2026
The Linux kernel contains a type confusion vulnerability within the Human Interface Device subsystem, specifically affecting the hid_scan_report function and its interaction with HID_GLOBAL_ITEM_TAG_REPORT_SIZE items encoded in long format. This flaw arises from an incorrect assumption regarding data storage formats during descriptor parsing. When fetch_item is invoked for an item tagged as HID_ITEM_TAG_LONG, it correctly stores a pointer to the item data within the item->data.longdata field rather than placing a value directly into the union fields such as u8, u16, or u32. However, subsequent functions like item_udata and item_sdata fail to verify this storage format before accessing the data. These functions incorrectly assume that all items are stored in short format, leading them to read from the wrong member of the union. Consequently, instead of retrieving a numeric value representing report size, these functions interpret the lower portion of a kernel pointer as an integer and return it for further processing or logging.
The operational impact of this vulnerability is primarily observed through information leakage via system logs rather than direct code execution or privilege escalation in most scenarios. When a HID device connects with a descriptor containing a long-format report size, the misinterpreted pointer value is printed into the kernel ring buffer dmesg as an invalid number. For example, users may see messages such as hid null: invalid report_size 107953555 appearing in system logs. This constitutes an information disclosure vulnerability because it exposes internal kernel memory addresses to local or potentially remote observers depending on how HID devices are managed and whether log access is restricted. While the bug specifically affects hid_scan_report, which is used for scanning reports rather than full parsing, the exposure of kernel pointer lower halves can aid attackers in bypassing Kernel Address Space Layout Randomization by providing clues about memory layout.
From a technical classification perspective, this issue aligns with CWE-843 Access of Resource Using Incompatible Type and CWE-200 Exposure of Sensitive Information to an Unauthorized Actor. The root cause is a failure to validate the data type or format before accessing it, leading to undefined behavior where pointer bits are treated as integer values. In terms of MITRE ATT&CK mapping, this vulnerability supports reconnaissance activities by allowing adversaries to gather information about kernel memory layout through log analysis if they can trigger the connection of malicious HID devices and access system logs. Although hid_parse_collections typically handles long items differently and bails out safely, the existence of any path that leaks internal pointers remains a security concern in modern operating systems where ASLR is a primary defense mechanism against exploitation techniques such as return-oriented programming or kernel exploit chaining.
Mitigation strategies should focus on both immediate code fixes and broader architectural improvements within the HID subsystem. The immediate fix involves modifying item_udata and item_sdata to explicitly check whether an item was stored in long format before attempting to read it from short-format union members. If a long-format item is detected, these functions should either return an error or handle the pointer appropriately without reinterpreting its bits as numeric data. Additionally, developers are advised to review the usage of data.longdata across the HID codebase. Since there may be no current users relying on this field for functional purposes beyond scanning, removing support for long-format descriptor parsing entirely could reduce attack surface and prevent similar type confusion bugs in future iterations. System administrators should ensure that dmesg access is restricted to privileged users where possible to limit the utility of any leaked pointer information until patches are applied.