CVE-2026-97923: tracing: Free histogram the var ref when its initialization fails
In the Linux kernel, the following vulnerability has been resolved:
tracing: Free histogram the var ref when its initialization fails
createvarref() allocates a VARREF histfield and then calls initvarref() to fill it in. When that fails the field is leaked.
commit 656fe2ba85e8 ("tracing: Use hist trigger's varref array to destroy varrefs") made destroyhistfield() return early for HISTFIELDFLVARREF, since var refs are freed by walking the trigger's varrefs[] array instead. createvarref() adds the field to that array only after initvarref() has succeeded, so on this path the field is in neither place and nothing frees it. The call was correct when it was written, before var refs were taken out of destroyhistfield().
initvarref() cannot free it either. The caller owns the field, so initvarref() undoes only its own string allocations and leaves the field alone. Freeing it there would leave createvarref() passing freed memory to destroyhistfield(), which reads its flags.
Call destroyhistfield(), which frees the field without consulting the flag.
Affected Software
Event History
Frequently Asked Questions
Under what condition does the memory leak occur?
The leak occurs when create_var_ref() allocates a VAR_REF histogram field but init_var_ref() fails. At that point, the field has not yet been added to the trigger's var_refs[] array, while normal histogram-field destruction skips VAR_REF fields.
Is this issue triggered during normal successful histogram variable-reference creation?
No. The described leak is limited to the initialization-failure path in create_var_ref(); successful initialization adds the variable reference to the trigger's var_refs[] array for later cleanup.
What is the implemented fix?
The failure path calls __destroy_hist_field(), which frees the allocated field without checking its VAR_REF flag. This avoids the early-return behavior in destroy_hist_field() that previously left the allocation unreleased.