CVE-2026-80781HID: core: fix OOB read of field->usage in hid_set_field()
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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>
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Sep 4, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 465544b3d6602cfbdc2305d5cbfb7f4954353b63; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 4993e1ab85d7d3f4a40d81852170f9665483bbd8; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 313ead1abed945544703b100a12c5a10fdf78409; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before c1d9c16af51cc6ff92a5a062617d3b022dd01078; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before a38212687519f2a72f43e62dec1348a690412404; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 9a1d7c5f0d82e8665715d5e47c9410c6a97e3748; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 5215ea00a747eca34cb2f603cfef91fef76c2558; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before cbcc0e8dea499e5ca86b583372ccb1815cccc570; and 1 more ranges | CNA record |
References
- https://git.kernel.org/stable/c/465544b3d6602cfbdc2305d5cbfb7f4954353b63
- https://git.kernel.org/stable/c/4993e1ab85d7d3f4a40d81852170f9665483bbd8
- https://git.kernel.org/stable/c/313ead1abed945544703b100a12c5a10fdf78409
- https://git.kernel.org/stable/c/c1d9c16af51cc6ff92a5a062617d3b022dd01078
- https://git.kernel.org/stable/c/a38212687519f2a72f43e62dec1348a690412404
- https://git.kernel.org/stable/c/9a1d7c5f0d82e8665715d5e47c9410c6a97e3748
- https://git.kernel.org/stable/c/5215ea00a747eca34cb2f603cfef91fef76c2558
- https://git.kernel.org/stable/c/cbcc0e8dea499e5ca86b583372ccb1815cccc570
- https://git.kernel.org/stable/c/a13cdb19fcb223ed41bdab3bab42b98dba87e90b
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.