[ CVE-2026-97921 · Published 25 Sep 2026 ]
Vulnerability in Linux
[ Description ]Official description
In the Linux kernel, the following vulnerability has been resolved: tracing: Free histogram the field rejected for a bad modifier Writing a hist trigger whose value or variable carries a modifier that is not allowed there leaks the fields that were built for it. __create_val_field() takes the field from parse_expr() and stores it in hist_data->fields[] only after the modifier checks have run: hist_field = parse_expr(hist_data, file, field_str, flags, var_name, &n_subexprs); ... if (hist_field->flags & HIST_FIELD_FL_VAR) { if (hist_field->flags & (...)) goto err; } else { if (hist_field->flags & (...)) goto err; } hist_data->fields[val_idx] = hist_field; Both checks jump past that store, and the err label returns without freeing anything. The error unwinds to create_hist_data(), which calls destroy_hist_data() -> destroy_hist_fields(), and that reaches a field only by walking fields[]. A field that never got there is unreachable. commit e0213434fe3e ("tracing: Do not let histogram values have some modifiers") set ret to -EINVAL and fell through to the store, which left the field owned by fields[] and freed along with the rest of hist_data. Splitting the check into a value case and a variable case replaced that fall-through with a goto that skips it. With CONFIG_DEBUG_KMEMLEAK, 200 writes of # echo 'hist:keys=prev_pid:vals=next_pid.log2' > \ events/sched/sched_switch/trigger each correctly rejected with -EINVAL, leave 332 unreferenced objects (63744 bytes) reported at create_hist_field(); 200 install and remove cycles of a valid trigger leave none. A '.log2' field is two allocations, since create_hist_field() puts the plain field in operands[0] of the log2 field, and both are reported. Use destroy_hist_field() rather than __destroy_hist_field() so that operands[0] is freed as well. It returns early for HIST_FIELD_FL_VAR_REF, which is what an operand owned by hist_data->var_refs[] needs; the rejected field itself is never a var ref, because a var ref never carries a modifier flag.
[ Fixes ]Fixes and patches
No fix or interim patch is linked from our sources yet. Check the vendor references below and limit exposure of affected systems until a fix is available.
[ Advisories ]Government CERT advisories
-
CERT-FRCERTFR-2026-AVI-1289
Multiple vulnerabilities in the Debian LTS Linux kernel Translated from French
Multiple vulnerabilities have been discovered in the Debian LTS Linux kernel. Some of them allow an attacker to cause privilege escalation, a breach of data confidentiality and denial of service.
-
CERT-FRCERTFR-2026-AVI-1253
Multiple vulnerabilities in the Debian Linux kernel Translated from French
Multiple vulnerabilities have been discovered in the Debian Linux kernel. Some of them allow an attacker to cause privilege escalation, a breach of data confidentiality and denial of service.
-
BSI CERT-BundWID-SEC-2026-3579
Linux Kernel: Multiple vulnerabilities Translated from German
[ References ]References
- git.kernel.org/stable/c/230234d12ce42ab04132a32c3a848f07a5d27a71
- git.kernel.org/stable/c/3d42fed18b2c5707b6332ebe87b789fd768eb01b
- git.kernel.org/stable/c/891c21f6d5673b2a519b536243bfc6dd2d35beb6
- git.kernel.org/stable/c/a2652fcf96b63e9da04951e4e58e6a0672df695d
- git.kernel.org/stable/c/b22dc0add7d72b8bd9cae3188db0dd65da1c8652
- git.kernel.org/stable/c/e787361bb6b0026ea3eb4d3fa7a304c7fcb99555