Skip to main content
VulnerabilityPublished Updated

CVE-2026-31624: Linux kernel · HID: core: clamp report_size in s32ton() to avoid undefined shift

Affects Linux kernelSource CVE Database V5

0
Compare

Not known to be exploited · fixed in eb415ddaf25e09ddb8fe5736a70c9de2e6462534 : update Linux kernel when convenient.

Data as of 6 Nov 2026, 16:04 UTC

Severity
Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

Thin evidence

One scorer or none
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Limited control over the software or limited information exposure

CISA SSVC assessment, 2026-11-06.

Patch
Available – fixed in eb415ddaf25e09ddb8fe5736a70c9de2e6462534, ea363a34086ddb4231adc581a7f36c39ec154bfc, 97014719bb8fccb1ffcbbc299e84b1f11b114195 +6

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 24 Apr 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 6 Nov 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ dde5845a529ff753364a6d1aea61180946270bfa, < eb415ddaf25e09ddb8fe5736a70c9de2e6462534
Fixed in
  • eb415ddaf25e09ddb8fe5736a70c9de2e6462534
LinuxLinuxAffected
  • ≥ dde5845a529ff753364a6d1aea61180946270bfa, < ea363a34086ddb4231adc581a7f36c39ec154bfc
Fixed in
  • ea363a34086ddb4231adc581a7f36c39ec154bfc
LinuxLinuxAffected
  • ≥ dde5845a529ff753364a6d1aea61180946270bfa, < 97014719bb8fccb1ffcbbc299e84b1f11b114195
Fixed in
  • 97014719bb8fccb1ffcbbc299e84b1f11b114195
LinuxLinuxAffected
  • ≥ dde5845a529ff753364a6d1aea61180946270bfa, < 58386f00af710922cafb0fb69211497beddfaa95
Fixed in
  • 58386f00af710922cafb0fb69211497beddfaa95
LinuxLinuxAffected
  • ≥ dde5845a529ff753364a6d1aea61180946270bfa, < 932ae5309e53561197aa7d1606c7cf63af10e24f
Fixed in
  • 932ae5309e53561197aa7d1606c7cf63af10e24f
LinuxLinuxAffected
  • ≥ dde5845a529ff753364a6d1aea61180946270bfa, < 76ad02854a30c394e0c076e6e6bed0a388573a94
Fixed in
  • 76ad02854a30c394e0c076e6e6bed0a388573a94

Description

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.

References

Community reviews

Loading reviews…