CVE-2026-97921

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

 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.