Skip to main content
← All vulnerabilities
CVE-2026-99163EUVD-2026-111915

tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields

Published
Last modified
published
Not listed in CISA KEV
Fix
Fixed in 5.11, 5.16, 6.2
None on Exploit-DB, Metasploit or GitHub

Summary

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().

Timeline

  1. CVE published
  2. First seen by cve.now

Affected versions

  • Linux Linux

    From 5.10.237 · fixed in 5.11; From 5.15.124 · fixed in 5.16; From 6.1.43 · fixed in 6.2

  • Linux Linux

    6.3

References 3

git.kernel.org