SEPTEMBER 18, 2026
Live Feed
Back to database
Case File

CVE-2026-80918

UNKNOWN · CVSS N/A EPSS 0.18%

Source: NVD + CISA KEV + EPSS · Published 2026-09-09 · Last synced 2026-09-18

CyberRota Analysis

AI-Generated

The vulnerability in the Linux kernel affects the handling of long-format HID items, where a pointer is incorrectly stored as a value, leading to potential exposure of kernel pointer data in system logs. This could allow an attacker to glean sensitive information from the kernel memory, particularly when specific HID devices are connected. System administrators and developers managing Linux environments with HID devices should prioritize addressing this issue to mitigate potential information leakage risks.

CVE
CVE-2026-80918
Severity
UNKNOWN
CVSS
N/A
EPSS
0.18%
Linux

Original NVD Description

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.