PT-2026-128156
CVE-2026-99163
·
Published
2026-10-28
·
Updated
2026-10-28
Description by
Score
N/A
Not availableNo 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().
Found an issue in the description? Have something to add? Feel free to write us 👾