CVE-2026-99163

HIGHCVSS 7.8/10EPSS 0.17%

Last modified

CVE-2026-99163 is a high-severity vulnerability rated 7.8/10 on the CVSS scale. 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().. EPSS estimates a 0.17% chance of exploitation in the next 30 days.

Description

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

Metrics

EPSS Probability
0.17%

6.6th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= b9453380c1c542fd095a4dbe9251eeba4022bbce, < eba0a6365a0f38f7598a02fc7f9ee341c7efe7f5; >= 5f52389bdd9eafb63b3a2f804e02aeb17b6a5f55, < 326c45c9e201e3ff4c9e9e0e14c2c91364d6c8be; >= f3baa42afeea0d5f04ad31525e861199d02210cc, < 6c4e4946febb585d2fc93a02a0cd12cec715bb32; >= 00cf3d672a9dd409418647e9f98784c339c3ff63, < 7e0d05a6234a984ac23b8a563fb7f66f2572b668; >= 00cf3d672a9dd409418647e9f98784c339c3ff63, < 648687f2b448d8527cd7b112fe5d4bd0fec85a87; >= 00cf3d672a9dd409418647e9f98784c339c3ff63, < 1f36e4ddd05d540f363dbaa4c23042549f15b3ef; >= 00cf3d672a9dd409418647e9f98784c339c3ff63, < deb336ae7c7b341591a6862cf6fcfeca97c77dfd; >= 00cf3d672a9dd409418647e9f98784c339c3ff63, < a244c241593b5b38a08f0df2cb43c26574efbdcb; >= 5.10.237, < 5.10.273; >= 5.15.124, < 5.15.224; >= 6.1.43, < 6.1.191
LinuxLinux6.3

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-99163?
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().
How severe is CVE-2026-99163?
CVE-2026-99163 has a CVSS score of 7.8/10 (HIGH severity). The EPSS model estimates a 0.17% probability of exploitation in the next 30 days.
How do I fix CVE-2026-99163?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-99163?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST