CVE-2026-80781: HID: core: fix OOB read of field->usage in hid_set_field()
In the Linux kernel, the following vulnerability has been resolved:
HID: core: fix OOB read of field->usage in hidsetfield()
hidsetfield() hands field->usage + offset to hiddumpinput() before the guard that bounds offset:
hiddumpinput(field->report->device, field->usage + offset, value);
if (offset >= field->reportcount) { hiderr(...); return -1; }
Under CONFIGDEBUGFS hiddumpinput() dereferences that pointer, with buf = hidresolvusage(usage->hid, NULL). The usage[] array is allocated inline with the hidfield in hidregisterfield() 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 < reportcount <= maxusage would already have confined the pointer to the array.
A caller supplies such an offset today. picolcdfbsendtile() validates only report->maxfield before issuing hidsetfield(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 hiddumpinput() below hidsetfield(), and the same boot logs "offset (1) exceeds reportcount (1)" from the guard that runs only afterwards.
Move the hiddumpinput() call below the guard. Because field->maxusage >= field->reportcount, 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 Software
Event History
Frequently Asked Questions
Which systems are exposed to the out-of-bounds read path described here?
The described dereference occurs when the kernel is built with CONFIG_DEBUG_FS. The reported triggering path involves the picolcd framebuffer code calling hid_set_field() with offsets 11 through 42 while the relevant HID field has fewer usages.
What condition is needed to trigger the faulty access?
A HID field must be registered with fewer usage entries than an offset supplied to hid_set_field(). In the described picolcd framebuffer path, deferred-I/O work repeatedly triggers the read when the device's field cannot accommodate the fixed tile offsets.
How can an administrator recognize this issue in diagnostics?
KASAN can report a 4-byte out-of-bounds read. The faulty access is through hid_dump_input() resolving field->usage plus an offset beyond the usage array allocation.
Is the issue tied to a particular configuration or feature?
The out-of-bounds pointer is dereferenced by hid_dump_input() under CONFIG_DEBUG_FS. The described caller is picolcd_fb_send_tile(), so the relevant exposure path also depends on the picolcd framebuffer deferred-I/O activity.