[PATCH] tracing/histograms: Fix use-after-free with same-name named triggers

[PATCH] tracing/histograms: Fix use-after-free with same-name named triggers

[Hui Su]

When two hist triggers on different events are registered with the same
name=, the second one reuses the first as named_data.  Both are added to
tr->hist_vars by save_hist_vars() during event_hist_trigger_parse(),
because save_hist_vars() is called before event_trigger_register() while
the named reuse is only detected later, in hist_register_trigger().

In the named-data branch hist_register_trigger() then frees the second
histogram's hist_data via destroy_hist_data(), but never removes its
tr->hist_vars list entry, leaving a dangling pointer and leaking the
trace_array reference it holds.

A later hist trigger that references a variable makes find_var_file()
walk tr->hist_vars and dereference the freed hist_data.  The bug is
reproducible from userspace by writing three hist triggers to tracefs:

  echo 'hist:keys=common_pid:x=common_pid:name=mh' > \
      /sys/kernel/tracing/events/sched/sched_switch/trigger
  echo 'hist:keys=common_pid:x=common_pid:name=mh' > \
      /sys/kernel/tracing/events/sched/sched_process_fork/trigger
  echo 'hist:keys=common_pid:vals=$x' > \
      /sys/kernel/tracing/events/sched/sched_process_exit/trigger

The third write panics the kernel:

  BUG: KASAN: slab-use-after-free in find_var_file.part.0+0x272/0x290
  Read of size 8 at addr ffff888001f8a0e0 by task sh/1
  CPU: 1 UID: 0 PID: 1 Comm: sh Tainted: G      D          N
  Call Trace:
    find_var_file.part.0
    find_event_var
    parse_atom
    parse_expr
    __create_val_field
    event_hist_trigger_parse
    trigger_process_regex
    event_trigger_write
    vfs_write
    ksys_write
    do_syscall_64
    entry_SYSCALL_64_after_hwframe
  Allocated by task 1:
    event_hist_trigger_parse
  Freed by task 1:
    hist_register_trigger+0x618/0xa30
    event_hist_trigger_parse
  The buggy address belongs to freed 2048-byte region
  Oops: general protection fault ... RIP: find_var_file.part.0
  Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

Fix by removing the hist_data from tr->hist_vars and releasing the
trace_array reference in the named-data branch of hist_register_trigger()
before freeing the hist_data.

Fixes: 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list")
Cc: stable@vger.kernel.org
Signed-off-by: Hui Su <sh_def@163.com>
---
 kernel/trace/trace_events_hist.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 58d28cd1afa3..6bf00710fd10 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -6641,8 +6641,10 @@ static int hist_register_trigger(char *glob,
 		tracing_set_filter_buffering(file->tr, true);
 	}
 
-	if (named_data)
+	if (named_data) {
+		remove_hist_vars(hist_data);
 		destroy_hist_data(hist_data);
+	}
  out:
 	return ret;
 }
-- 
2.54.0

Re: [PATCH] tracing/histograms: Fix use-after-free with same-name named triggers

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Missing rollback of data->ops->init() when tracing_set_clock() fails, leading to a use-after-free in the global named_triggers list.
- [Critical] Double-free and use-after-free of `hist_data` and global list corruption of `trigger_data` when a reused named trigger successfully registers but fails to enable.
--

--- Patch [1]: [PATCH] tracing/histograms: Fix use-after-free with same-name named triggers ---
commit 5aedb1f49e82add364d36e7e38374f9abcb9b2b9
Author: Hui Su <sh_def@163.com>

tracing/histograms: Fix use-after-free with same-name named triggers

When two hist triggers on different events are registered with the same
name=, the second one reuses the first as named_data. Both are added to
tr->hist_vars by save_hist_vars() during event_hist_trigger_parse(),
but the named reuse is only detected later. This commit fixes a dangling
pointer issue by properly removing the hist_data from tr->hist_vars before
freeing it.

> diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
> index fdf784620c283..50e86f81ea32a 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -6044,8 +6044,10 @@ static int hist_register_trigger(char *glob,
>  		tracing_set_filter_buffering(file->tr, true);
>  	}
>  

[Severity: Critical]
This is a pre-existing issue, but I noticed a potential problem in the error
handling right above this block when tracing_set_clock() fails.

If tracing_set_clock() fails, the code executes goto out, returning without
rolling back the data->ops->init() call that added the trigger to the global
list.

Would this result in event_hist_trigger_parse() executing kfree(trigger_data)
via its out_free path while trigger_data->named_list is still linked in the
global named_triggers list? Could this lead to a slab-use-after-free during
global list traversal?

> -	if (named_data)
> +	if (named_data) {
> +		remove_hist_vars(hist_data);
>  		destroy_hist_data(hist_data);

[Severity: Critical]
This is another pre-existing issue, but might freeing hist_data here cause a
double-free if registration ultimately fails?

When reusing a named trigger, hist_data is freed here. However, it appears
event_hist_trigger_parse() does not update its local hist_data pointer. If
a subsequent operation like hist_trigger_enable() fails, will the out_free
path in event_hist_trigger_parse() execute remove_hist_vars() and
destroy_hist_data() on the already-freed hist_data pointer?

Additionally, it seems kfree(trigger_data) would be called in that same
error path without unlinking it from the global named_triggers list. Can this
corrupt the global list?

> +	}
>   out:
>  	return ret;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260816100427.33642-3-sh_def@163.com?part=1