PT-2026-128156

CVE-2026-99163

·

Published

2026-10-28

·

Updated

2026-10-28

Description by

Score
N/A
Not available

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.

In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields
In check synth field(), when a synthetic event field is a stacktrace (field->is stack) and the histogram field is not a "long[" stacktrace array, validation falls through to the generic size and signedness comparison.
Because parse synth field() sets a stacktrace field's type to " data loc unsigned long[]", its size is sizeof(u64) and synth field signed() marks it as signed. Consequently, any 8-byte signed scalar histogram field passes the fallback check, and its scalar value is subsequently dereferenced as a kernel stacktrace pointer in get field size() and trace stack().
Furthermore, checking strstr(hist field->type, "long[") is insufficient because tracepoint fields defined with bitmask() or rel bitmask() also have type " data loc unsigned long[]" or " rel loc unsigned long[]", whilst create hist field() treats them as 4-byte scalar values without HIST FIELD FL STACKTRACE.
Propagate HIST FIELD FL STACKTRACE to variable references and field variables (whilst excluding variable aliases from per-element stacktrace capture), and reject any mismatch between HIST FIELD FL STACKTRACE and field->is stack in check synth field().
Vendors
Affected products
Related identifiers
Found an issue in the description? Have something to add? Feel free to write us 👾