UBUNTU-CVE-2026-97921: Medium severity ubuntu/linux-hwe-edge vulnerability

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.