HID: core: clamp report_size in s32ton() to avoid undefined shift
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 report_size, a value that comes directly from a HID device. The HID parser bounds report_size 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 hid_output_field() or hid_set_field(). Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in hid_report_raw_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.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.258, 5.15.209, 6.1.175, 6.12.83, 6.18.24, 6.19.14, 6.6.136, 7.0.1
- CVEs
- CVE-2026-31624
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 23:11 UTC · Revision 1
Source evidence
HID: core: clamp report_size in s32ton() to avoid undefined shift
core-osv · Original sourcePublished 24 Apr 2026, 14:42 UTC
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 report_size, a value that comes directly from a HID device. The HID parser bounds report_size 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 hid_output_field() or hid_set_field(). Commit ec61b41918587 ("HID: core: fix shift-out-of-bounds in hid_report_raw_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:CVE-2026-31624
Kernel
Fixed versions: 5.10.258, 5.15.209, 6.1.175, 6.6.136, 6.12.83, 6.18.24, 6.19.14, 7.0.1
Complete source record
{
"id": "6950f077f81457d650cc9fbb35c907ecb149c506e98509c0d3cae1acf89c11f0",
"url": "https://osv.dev/vulnerability/CVE-2026-31624",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "HID: core: clamp report_size in s32ton() to avoid undefined shift",
"summary": "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 report_size, a value that comes directly from a HID device. The HID parser bounds report_size 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 hid_output_field() or hid_set_field(). Commit ec61b41918587 (\"HID: core: fix shift-out-of-bounds in hid_report_raw_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.",
"evidence": "osv:CVE-2026-31624",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.10.258",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.209",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.175",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.136",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.83",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.24",
"evidence": "/affected/1/ranges"
},
{
"value": "6.19.14",
"evidence": "/affected/1/ranges"
},
{
"value": "7.0.1",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-31624",
"aliases": [
"CVE-2026-31624"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "dde5845a529ff753364a6d1aea61180946270bfa"
},
{
"fixed": "76ad02854a30c394e0c076e6e6bed0a388573a94"
},
{
"fixed": "eb415ddaf25e09ddb8fe5736a70c9de2e6462534"
},
{
"fixed": "0ab048dbdb1daacf17d52e9252297eb6e1298e49"
},
{
"fixed": "932ae5309e53561197aa7d1606c7cf63af10e24f"
},
{
"fixed": "58386f00af710922cafb0fb69211497beddfaa95"
},
{
"fixed": "8a8333237f1f5caab8d4c3d2c2e7578c4263a97f"
},
{
"fixed": "ea363a34086ddb4231adc581a7f36c39ec154bfc"
},
{
"fixed": "97014719bb8fccb1ffcbbc299e84b1f11b114195"
},
{
"fixed": "69c02ffde6ed4d535fa4e693a9e572729cad3d0d"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31624.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "2.6.20"
},
{
"fixed": "5.10.258"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.209"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.175"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.136"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.83"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.24"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "6.19.14"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.20.0"
},
{
"fixed": "7.0.1"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31624.json"
}
}
],
"modified": "2026-10-28T02:30:40.283410614Z",
"provider": "osv",
"references": [
"https://cert-portal.siemens.com/productcert/html/ssa-784472.html",
"https://git.kernel.org/stable/c/0ab048dbdb1daacf17d52e9252297eb6e1298e49",
"https://git.kernel.org/stable/c/58386f00af710922cafb0fb69211497beddfaa95",
"https://git.kernel.org/stable/c/69c02ffde6ed4d535fa4e693a9e572729cad3d0d",
"https://git.kernel.org/stable/c/76ad02854a30c394e0c076e6e6bed0a388573a94",
"https://git.kernel.org/stable/c/8a8333237f1f5caab8d4c3d2c2e7578c4263a97f",
"https://git.kernel.org/stable/c/932ae5309e53561197aa7d1606c7cf63af10e24f",
"https://git.kernel.org/stable/c/97014719bb8fccb1ffcbbc299e84b1f11b114195",
"https://git.kernel.org/stable/c/ea363a34086ddb4231adc581a7f36c39ec154bfc",
"https://git.kernel.org/stable/c/eb415ddaf25e09ddb8fe5736a70c9de2e6462534",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31624.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-31624",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31624.json"
}
},
"related_cves": [
{
"value": "CVE-2026-31624",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 507873,
"published_at": "2026-04-24T14:42:41.655+00:00"
}