Homepage

CVE-2026-80781 Affecting python3-perf package, versions <1:6.1.186-228.374.amzn2023

Severity

 Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.2% (10th 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-PYTHON3PERF-19818654
  • published15 Sept 2026
  • disclosed4 Sept 2026
Report a new vulnerability Found a mistake?

Introduced: 4 Sep 2026

NewCVE-2026-80781  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 python3-perf to version 1:6.1.186-228.374.amzn2023 or higher.
This issue was patched in ALAS2023-2026-2143.

NVD Description

Note: Versions mentioned in the description apply only to the upstream python3-perf package and not the python3-perf 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: 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-&gt;report-&gt;device, field-&gt;usage + offset, value);


if (offset &gt;= field-&gt;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>