Incorrect Bitwise Shift of Integer Affecting perf6.18-debuginfo package, versions <1:6.18.25-55.108.amzn2023


Severity

Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.01% (3rd percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-AMZN2023-PERF618DEBUGINFO-16736452
  • published18 May 2026
  • disclosed24 Apr 2026

Introduced: 24 Apr 2026

CVE-2026-31624  (opens in a new tab)
CWE-1335  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 perf6.18-debuginfo to version 1:6.18.25-55.108.amzn2023 or higher.
This issue was patched in ALAS2023-2026-1693.

NVD Description

Note: Versions mentioned in the description apply only to the upstream perf6.18-debuginfo package and not the perf6.18-debuginfo package as distributed by Amazon-Linux. See How to fix? for Amazon-Linux:2023 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1