Linux Kernel up to 6.18.58/7.2.12 Histograms check_synth_field stack-based overflow

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 7.4 | $0-$5k | 1.05 |
Summary
A vulnerability has been found in Linux Kernel up to 6.18.58/7.2.12 and classified as critical. Affected is the function check_synth_field of the component Histograms. Performing a manipulation results in stack-based overflow.
This vulnerability is cataloged as CVE-2026-99163. The attack must be initiated from a local position. There is no exploit available.
The affected component should be upgraded.
Details
A vulnerability, which was classified as critical, was found in Linux Kernel up to 6.18.58/7.2.12. This affects the function check_synth_field of the component Histograms. The manipulation with an unknown input leads to a stack-based overflow vulnerability. CWE is classifying the issue as CWE-121. A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function). This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:
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().
It is possible to read the advisory at git.kernel.org. This vulnerability is uniquely identified as CVE-2026-99163 since 09/25/2026. The exploitability is told to be easy. Attacking locally is a requirement. Additional levels of successful authentication are needed for exploitation. It demands that the victim is doing some kind of user interaction. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $0-$5k at the moment (estimation calculated on 10/28/2026).
Upgrading to version 6.18.59 or 7.2.13 eliminates this vulnerability. Applying the patch 1f36e4ddd05d540f363dbaa4c23042549f15b3ef/deb336ae7c7b341591a6862cf6fcfeca97c77dfd/a244c241593b5b38a08f0df2cb43c26574efbdcb is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Product
Type
Vendor
Name
Version
- 6.18.0
- 6.18.1
- 6.18.2
- 6.18.3
- 6.18.4
- 6.18.5
- 6.18.6
- 6.18.7
- 6.18.8
- 6.18.9
- 6.18.10
- 6.18.11
- 6.18.12
- 6.18.13
- 6.18.14
- 6.18.15
- 6.18.16
- 6.18.17
- 6.18.18
- 6.18.19
- 6.18.20
- 6.18.21
- 6.18.22
- 6.18.23
- 6.18.24
- 6.18.25
- 6.18.26
- 6.18.27
- 6.18.28
- 6.18.29
- 6.18.30
- 6.18.31
- 6.18.32
- 6.18.33
- 6.18.34
- 6.18.35
- 6.18.36
- 6.18.37
- 6.18.38
- 6.18.39
- 6.18.40
- 6.18.41
- 6.18.42
- 6.18.43
- 6.18.44
- 6.18.45
- 6.18.46
- 6.18.47
- 6.18.48
- 6.18.49
- 6.18.50
- 6.18.51
- 6.18.52
- 6.18.53
- 6.18.54
- 6.18.55
- 6.18.56
- 6.18.57
- 6.18.58
- 7.2.0
- 7.2.1
- 7.2.2
- 7.2.3
- 7.2.4
- 7.2.5
- 7.2.6
- 7.2.7
- 7.2.8
- 7.2.9
- 7.2.10
- 7.2.11
- 7.2.12
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 7.7VulDB Meta Temp Score: 7.4
VulDB Base Score: 7.7
VulDB Temp Score: 7.4
VulDB Vector: 🔒
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Stack-based overflowCWE: CWE-121 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒
Physical: Partially
Local: Yes
Remote: Partially
Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: Kernel 6.18.59/7.2.13
Patch: 1f36e4ddd05d540f363dbaa4c23042549f15b3ef/deb336ae7c7b341591a6862cf6fcfeca97c77dfd/a244c241593b5b38a08f0df2cb43c26574efbdcb
Timeline
09/25/2026 CVE reserved10/28/2026 Advisory disclosed
10/28/2026 VulDB entry created
10/28/2026 VulDB entry last update
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2026-99163 (🔒)
GCVE (CVE): GCVE-0-2026-99163
GCVE (VulDB): GCVE-100-427899
Entry
Created: 10/28/2026 12:44Changes: 10/28/2026 12:44 (59)
Complete: 🔍
Cache ID: 216::103
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
No comments yet. Languages: en.
Please log in to comment.