CVE-2026-80781 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
HID: core: fix OOB read of field->usage in hid_set_field()
hid_set_field() hands field->usage + offset to hid_dump_input() before the guard that bounds offset:
hid_dump_input(field->report->device, field->usage + offset, value);
if (offset >= field->report_count) {
hid_err(...); return -1; }
Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with buf = hid_resolv_usage(usage->hid, NULL). The usage[] array is
allocated inline with the hid_field in hid_register_field() and holds field->maxusage entries, so an offset past it reads off the end of the kvzalloc()ed allocation and into a neighbouring object. Had the guard run first, offset < report_count <= maxusage would already have confined the pointer to the array.
A caller supplies such an offset today. picolcd_fb_send_tile() validates only report->maxfield before issuing hid_set_field(report->field[0], 11 + i, ...) for i = 0..31, so its
offsets are fixed at 11..42 and are never checked against the bound field. When the device registers that field with fewer usages, the framebuffer deferred-io work drives the read on every tile. KASAN reports a 4-byte slab-out-of-bounds read in hid_dump_input() below hid_set_field(), and the same boot logs "offset (1) exceeds report_count (1)" from the guard that runs only afterwards.
Move the hid_dump_input() call below the guard. Because field->maxusage >= field->report_count, the guard then establishes that field->usage + offset lies inside the array before it is dereferenced, for every caller and without changing behaviour on the valid path.
Discovered by XBOW, triaged by Baul Lee <[email protected]>
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel contains a critical out-of-bounds read vulnerability within the Human Interface Device subsystem, specifically located in the hid_set_field function. This flaw arises from an incorrect ordering of operations that leads to memory safety violations when processing HID report fields. The core issue is that the code invokes hid_dump_input with a pointer calculated as field->usage plus offset before verifying whether the offset exceeds the valid bounds defined by field->report_count. Under configurations where DEBUG_FS is enabled, this function call results in dereferencing an invalid memory address because the guard condition checking for excessive offsets executes only after the potentially dangerous operation has already occurred. This structural defect allows attackers to trigger a slab-out-of-bounds read if they can supply crafted input that causes the offset calculation to exceed the allocated array limits.
The technical root cause lies in how hid_dump_input interacts with memory allocation structures during runtime diagnostics. When DEBUG_FS is active, hid_dump_input attempts to resolve usage codes by accessing an internal usage array associated with each HID field. This array is dynamically allocated inline within the hid_field structure via kvzalloc and sized according to maxusage entries. However, because the offset validation against report_count happens too late in the execution flow, any offset value that exceeds report_count but remains below or near maxusage can still cause an out-of-bounds access if it pushes past the actual allocated boundary of the usage array. In practice, this manifests as a four-byte slab-out-of-bounds read detected by Kernel Address Sanitizer when processing malformed device reports. The vulnerability is particularly insidious because standard bounds checking logic exists but is rendered ineffective due to its placement after the memory dereference point rather than before it.
Operational impact of this vulnerability includes potential information disclosure and system instability depending on what data resides in adjacent kernel memory regions accessed by the out-of-bounds read. An attacker with physical access or control over connected HID devices could exploit this flaw to leak sensitive kernel memory contents, potentially revealing cryptographic keys, process credentials, or other confidential data structures residing near the affected allocation. Additionally, repeated exploitation may lead to unpredictable system behavior including crashes or denial of service conditions as corrupted reads propagate through subsequent processing stages. The specific trigger involves drivers like picolcd_fb_send_tile which validate only report-level field counts rather than individual field usage limits, allowing fixed offsets that exceed per-field boundaries when devices register fewer usages than expected by the driver logic.
This vulnerability aligns with Common Weakness Enumeration category CWE-125 representing Out-of-bounds Read and maps to MITRE ATT&CK technique T1083 which involves File and Directory Discovery through kernel memory inspection capabilities enabled via debug interfaces. The exploitation path typically requires local physical access or compromised peripheral devices capable of sending specially crafted HID reports that trigger the problematic code path during framebuffer updates or similar deferred-io operations. Security researchers from XBOW discovered this issue while triaging potential kernel vulnerabilities, highlighting the importance of rigorous static analysis and runtime sanitization tools in identifying subtle ordering defects within complex subsystems like input device handling.
Mitigation strategies primarily involve applying upstream kernel patches that reorder the hid_dump_input call to occur after proper bounds checking has been performed. System administrators should ensure their Linux kernels are updated with fixes addressing this specific HID core vulnerability, particularly those released following discovery by XBOW and triaged by Baul Lee. For environments where DEBUG_FS cannot be disabled due to diagnostic requirements, strict validation of incoming HID report structures becomes essential to prevent malformed inputs from reaching vulnerable code paths. Developers integrating new HID drivers must implement comprehensive checks ensuring that all offset calculations respect both report_count constraints and maxusage limits before invoking any functions that dereference usage arrays or perform memory accesses based on calculated pointers.