CVE-2026-80781

CVE CVE-2026-80781EUVD EUVD-2026-71424Published 2026-09-04T15:12:52.000Z

What the advisory describes

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>

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux patch: 6.18.47; patch: 0; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <9a1d7c5f0d82e8665715d5e47c9410c6a97e3748; patch: 6.6.154; patch: 7.3-rc1; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <5215ea00a747eca34cb2f603cfef91fef76c2558; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <465544b3d6602cfbdc2305d5cbfb7f4954353b63; patch: 6.12.106; patch: 7.2.1; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <a13cdb19fcb223ed41bdab3bab42b98dba87e90b; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <a38212687519f2a72f43e62dec1348a690412404; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <c1d9c16af51cc6ff92a5a062617d3b022dd01078; 2.6.12; patch: 5.15.218; patch: 5.10.267; patch: 7.1.11; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <4993e1ab85d7d3f4a40d81852170f9665483bbd8; patch: 6.1.185; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <cbcc0e8dea499e5ca86b583372ccb1815cccc570; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <313ead1abed945544703b100a12c5a10fdf78409

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.