AZL-99407

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:

hid_dump_input(field->report->device, field->usage + offset, value);

if (offset >= field->report_count) {
    hid_err(...);
    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->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