CVE-2026-97921: tracing: Free histogram the field rejected for a bad modifier
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.
createvalfield() takes the field from parseexpr() and stores it in histdata->fields[] only after the modifier checks have run:
histfield = parseexpr(histdata, file, fieldstr, flags, varname, &nsubexprs); ... if (histfield->flags & HISTFIELDFLVAR) { if (histfield->flags & (...)) goto err; } else { if (histfield->flags & (...)) goto err; }
histdata->fields[validx] = histfield;
Both checks jump past that store, and the err label returns without freeing anything. The error unwinds to createhistdata(), which calls destroyhistdata() -> destroyhistfields(), 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 histdata. Splitting the check into a value case and a variable case replaced that fall-through with a goto that skips it.
With CONFIGDEBUGKMEMLEAK, 200 writes of
# echo 'hist:keys=prevpid:vals=nextpid.log2' > \ events/sched/schedswitch/trigger
each correctly rejected with -EINVAL, leave 332 unreferenced objects (63744 bytes) reported at createhistfield(); 200 install and remove cycles of a valid trigger leave none. A '.log2' field is two allocations, since createhistfield() puts the plain field in operands[0] of the log2 field, and both are reported.
Use destroyhistfield() rather than destroyhistfield() so that operands[0] is freed as well. It returns early for HISTFIELDFLVARREF, which is what an operand owned by histdata->varrefs[] needs; the rejected field itself is never a var ref, because a var ref never carries a modifier flag.
Affected Software
Event History
Frequently Asked Questions
What action triggers the leak?
The leak is triggered by writing a tracing histogram trigger whose value or variable uses a modifier that is not allowed in that context. The invalid modifier causes an error path before the newly created field is stored for normal cleanup.
What is leaked and why is normal cleanup ineffective?
The leaked object is the field built while parsing the invalid histogram expression. Because it is not added to hist_data->fields[] before the modifier validation fails, destroy_hist_data() cannot reach and free it during error unwinding.
Is this caused by a successful histogram configuration?
No. The issue occurs when processing a rejected histogram value or variable expression with a disallowed modifier. The failure path returns an error but leaves the parsed field allocated.