[PATCH] tracing: hist: free the var ref when its initialization fails

create_var_ref() allocates a VAR_REF hist_field and then calls
init_var_ref() to fill it in. When that fails the field is leaked.

commit 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy
var_refs") made destroy_hist_field() return early for
HIST_FIELD_FL_VAR_REF, since var refs are freed by walking the trigger's
var_refs[] array instead. create_var_ref() adds the field to that array
only after init_var_ref() 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 destroy_hist_field().

init_var_ref() cannot free it either. The caller owns the field, so
init_var_ref() undoes only its own string allocations and leaves the
field alone. Freeing it there would leave create_var_ref() passing freed
memory to destroy_hist_field(), which reads its flags.

Call __destroy_hist_field(), which frees the field without consulting
the flag.

Fixes: 656fe2ba85e8 ("tracing: Use hist trigger's var_ref array to destroy var_refs")
Signed-off-by: Donggeun Yoo <redacted>
---
Found by the Sashiko bot while reviewing an unrelated hist trigger patch:
https://lore.kernel.org/linux-trace-kernel/20260906124025.3550596-1-donggeunyoo.kernel@gmail.com/ (local)

That patch and this one are independent; this applies with or without it.

init_var_ref() only fails when kstrdup() returns NULL, so to reproduce it I
built a kernel with its last allocation forced to fail, leaving everything
else stock, and installed

  hist:keys=next_pid:delta=common_timestamp-$start

200 times against a sched_waking trigger defining $start. All 200 installs
fail, as intended; the question is what each failure leaves behind. With
CONFIG_DEBUG_KMEMLEAK:

  before  200 unreferenced objects, 38400 bytes
  after     0 unreferenced objects,     0 bytes

38400 is 200 * 192, one struct hist_field per failed call, which also
confirms the strings are not leaked: init_var_ref() frees those itself.
kmemleak points at the allocation in create_hist_field() reached from
create_var_ref().

checkpatch --strict is clean and an x86_64 W=1 build of the file adds no
warnings.

 kernel/trace/trace_events_hist.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 963e0d6b61fd..34831a01bb9b 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c

@@ -2234,7 +2234,7 @@ static struct hist_field *create_var_ref(struct hist_trigger_data *hist_data,
 	ref_field = create_hist_field(var_field->hist_data, NULL, flags, NULL);
 	if (ref_field) {
 		if (init_var_ref(ref_field, var_field, system, event_name)) {
-			destroy_hist_field(ref_field, 0);
+			__destroy_hist_field(ref_field);
 			return NULL;
 		}
 

base-commit: 1fc5a74b108fc90951890ec513ac81869f5eaff1
-- 
2.53.0