In the Linux kernel, the following vulnerability has been resolved:
HID: core: clamp report_size in s32ton() to avoid undefined shift
s32ton() shifts by n-1 where n is the field's reportsize, a value that comes directly from a HID device. The HID parser bounds reportsize only to <= 256, so a broken HID device can supply a report descriptor with a wide field that triggers shift exponents up to 256 on a 32-bit type when an output report is built via hidoutputfield() or hidsetfield().
Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in hidreportraw_event") added the same n > 32 clamp to the function snto32(), but s32ton() was never given the same fix as I guess syzbot hadn't figured out how to fuzz a device the same way.
Fix this up by just clamping the max value of n, just like snto32() does.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31624.json",
"cna_assigner": "Linux"
}