summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/stackcollapse-report
diff options
context:
space:
mode:
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>2026-04-06 16:04:10 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2026-04-22 13:32:15 +0200
commit97014719bb8fccb1ffcbbc299e84b1f11b114195 (patch)
tree29d1776491daa67280c260b48b551141c005054a /tools/perf/scripts/python/bin/stackcollapse-report
parentee2cb3ddfdca949dbc0c3f796ed5a439f0efc9f6 (diff)
downloadkernel-97014719bb8fccb1ffcbbc299e84b1f11b114195.tar.gz
HID: core: clamp report_size in s32ton() to avoid undefined shift
commit 69c02ffde6ed4d535fa4e693a9e572729cad3d0d upstream. 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. Cc: stable <stable@kernel.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <bentiss@kernel.org> Cc: linux-input@vger.kernel.org Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jiri Kosina <jkosina@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-report')
0 files changed, 0 insertions, 0 deletions