CVE-2026-80781
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A bug in how the Linux kernel handles certain input devices can let specially crafted hardware read a little extra memory it should not, which might cause crashes until the system software is updated.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
Out-of-bounds read in hid_set_field() where hid_dump_input() dereferences field->usage + offset before the offset >= report_count guard; the usage array allocated with maxusage entries can be overrun when a caller supplies an unchecked offset, leading to a 4-byte slab read into adjacent kernel memory under CONFIG_DEBUG_FS.
Why it matters to the business
Kernel instability, crashes, or limited memory disclosure possible on Linux systems using affected HID devices such as certain LCD panels; low exploitation probability reduces immediate risk but still requires patching to maintain system reliability.
How an attack unfolds
An attacker supplies a malicious or misbehaving HID device whose registered field has report_count smaller than the offsets later passed by picolcd_fb_send_tile(); the framebuffer deferred-io work then repeatedly invokes hid_set_field with offsets 11-42, hitting the unguarded dereference in hid_dump_input during normal device operation.
How to fix it
Apply the upstream fix that moves the hid_dump_input call below the offset guard in hid_set_field; rebuild and deploy updated Linux kernels containing the corrected HID core logic.
How to confirm the fix worked
Confirm the patch is present by inspecting the source of hid_set_field to ensure hid_dump_input occurs after the report_count check; boot with the triggering device and verify absence of KASAN slab-out-of-bounds reports and offset-exceeds-report_count messages.
Typical attack path
- Connect or enumerate a HID device that registers a hid_field with low report_count relative to later offsets
- Trigger framebuffer tile updates via picolcd_fb_send_tile calling hid_set_field with fixed offsets 11-42
- hid_set_field executes hid_dump_input on the out-of-bounds usage pointer before the bounds check
- KASAN or kernel logging records slab-out-of-bounds read and subsequent error message
How to detect it
Inspect kernel logs and dmesg for strings containing 'offset exceeds report_count' and KASAN reports mentioning hid_dump_input or hid_set_field; correlate with HID device enumeration events from the same boot session.
- offset (\d+) exceeds report_count
- slab-out-of-bounds read in hid_dump_input
- hid_set_field.*usage
What your security team should do
- Prioritize kernel updates for systems exposing HID devices to untrusted hardware
- Disable CONFIG_DEBUG_FS on production kernels where feasible to reduce attack surface
- Monitor boot and dmesg logs for hid_err messages referencing report_count after applying updates
The record
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 <baul.lee@xbow.com>
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|