CVE Catalog

CVE-2026-97921

Unknown
Published: Translated: NVD NIST

Summary

A vulnerability in the Linux kernel tracing subsystem (histograms) causes a memory leak when a histogram field is rejected due to an invalid modifier (e.g., .log2). The field is not properly freed because it is not added to the fields[] list before the error path. This can lead to unreferenced objects and memory exhaustion.

Risk Assessment

The memory leak can gradually exhaust system memory, potentially causing system instability or denial of service (DoS). An attacker with write access to tracefs (e.g., root) can repeatedly trigger this vulnerability to amplify the impact.

Recommendation

Apply a Linux kernel update containing the fix (commit e0213434fe3e and related). If not possible, restrict access to the tracefs interface (e.g., via permissions) and monitor memory usage for anomalies.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS