CVE-2026-99163: Linux kernel · tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields
Affects Linux kernelSource GCVE Database
Not known to be exploited.
Data as of 29 Oct 2026, 22:35 UTC
Rated by Threat Radar · CVSS not yet scored by NVD
Thin evidence
One scorer or noneExploitation evidence
Disclosed: evidence found.
CVE published 28 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Ubuntu 26.10linuxpkg:deb/ubuntu/linux?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-awspkg:deb/ubuntu/linux-aws?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-azurepkg:deb/ubuntu/linux-azure?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-azure-fdepkg:deb/ubuntu/linux-azure-fde?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-gcppkg:deb/ubuntu/linux-gcp?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Ubuntu 26.10linux-oraclepkg:deb/ubuntu/linux-oracle?arch=source&distro=stonkingOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
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().
References
- ubuntu.com/security/CVE-2026-99163 (opens in a new tab)
- cve.org/CVERecord?id=CVE-2026-99163 (opens in a new tab)
- git.kernel.org/stable/c/deb336ae7c7b341591a6862cf6fcfeca97c77dfd (opens in a new tab)
- git.kernel.org/stable/c/1f36e4ddd05d540f363dbaa4c23042549f15b3ef (opens in a new tab)
- git.kernel.org/stable/c/a244c241593b5b38a08f0df2cb43c26574efbdcb (opens in a new tab)