CVE-2026-99163: tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields

Published Oct 28, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

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

In checksynthfield(), when a synthetic event field is a stacktrace (field->isstack) and the histogram field is not a "long[" stacktrace array, validation falls through to the generic size and signedness comparison.

Because parsesynthfield() sets a stacktrace field's type to "dataloc unsigned long[]", its size is sizeof(u64) and synthfieldsigned() 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 getfieldsize() and tracestack().

Furthermore, checking strstr(histfield->type, "long[") is insufficient because tracepoint fields defined with bitmask() or relbitmask() also have type "dataloc unsigned long[]" or "relloc unsigned long[]", whilst createhistfield() treats them as 4-byte scalar values without HISTFIELDFLSTACKTRACE.

Propagate HISTFIELDFLSTACKTRACE to variable references and field variables (whilst excluding variable aliases from per-element stacktrace capture), and reject any mismatch between HISTFIELDFLSTACKTRACE and field->isstack in checksynthfield().

Affected Software

1 affected component

Linux Linux kernel

Event History

Oct 28, 2026

CVE Published

via MITRE·10:35 AM

Data Sourced

via MITRE·10:35 AM

Description

Data Sourced

via NVD·11:17 AM

Description

Frequently Asked Questions

Which systems are exposed to this issue?

Exposure requires use of Linux kernel tracing histograms with synthetic event fields that are treated as stacktraces. The problematic cases involve a synthetic stacktrace field associated with a histogram field that is not a valid stacktrace array, including certain bitmask or relative-bitmask tracepoint fields.

What condition triggers the unsafe behavior?

A signed 8-byte scalar histogram field can pass the prior generic validation for a synthetic stacktrace field. Its scalar value may then be dereferenced as a kernel stacktrace pointer during field-size handling and stack tracing.

How can I identify potentially affected tracing definitions?

Review synthetic-event histogram definitions that use stacktrace fields and verify that their source fields are actual stacktrace arrays rather than scalar fields. Pay particular attention to fields with __data_loc unsigned long[] or __rel_loc unsigned long[] types that originate from __bitmask() or __rel_bitmask(), because they may be handled as 4-byte scalars rather than stacktrace fields.

What is the available remediation?

Use a Linux kernel version containing the fix referenced by the provided stable commits. The fix rejects incompatible fields for synthetic stacktrace fields and propagates the stacktrace field flag through relevant variable references and field variables.

CVE-2026-99163: tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields

Affected Software

Event History

Frequently Asked Questions

Which systems are exposed to this issue?

What condition triggers the unsafe behavior?

How can I identify potentially affected tracing definitions?

What is the available remediation?

Company

Resources

Contact

Frequently Asked Questions

Which systems are exposed to this issue?

What condition triggers the unsafe behavior?

How can I identify potentially affected tracing definitions?

What is the available remediation?