CVE-2026-80781

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