[PATCH] tracing: hist: set the trace clock before registering the trigger

[PATCH] tracing: hist: set the trace clock before registering the trigger

[Donggeun Yoo]

hist_register_trigger() puts the trigger on the global named_triggers
list in cmd_ops->init(), and only then sets the trace clock:

	if (data->cmd_ops->init) {
		ret = data->cmd_ops->init(data);
		if (ret < 0)
			goto out;
	}

	if (hist_data->enable_timestamps) {
		ret = tracing_set_clock(file->tr, hist_data->attrs->clock);
		if (ret) {
			hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock));
			goto out;
		}

The clock string is not checked anywhere before that call, so a named
trigger using common_timestamp with an unknown clock fails after it has
already become findable. event_hist_trigger_parse() then frees it
without taking it off the list, and the next lookup by name reads the
freed object:

 ~# cd /sys/kernel/tracing/events/sched/sched_switch
 ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger
 bash: echo: write error: Invalid argument
 ~# echo 'hist:name=foo:keys=common_pid' > trigger

  BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
  Read of size 8 at addr ffff88800915d760 by task init/1
   find_named_trigger+0xac/0xc0
   hist_register_trigger+0xc1/0x900
   event_hist_trigger_parse+0x3146/0x6af0
   event_trigger_write+0xce/0x160
  Freed by task 63:
   kfree+0x154/0x420
   trigger_kthread_fn+0xfd/0x160

Set the clock before the trigger is registered, so that nothing which
can fail runs after it is published, the way commit 6f86bdeab633
("tracing: Fix bad hist from corrupting named_triggers list") moved the
registration below the rest of the setup.

tracing_set_filter_buffering() is reference counted, so the init failure
path has to drop the reference that the clock block now takes first.

Fixes: a4072fe85ba3 ("tracing: Add a clock attribute for hist triggers")
Cc: stable@vger.kernel.org
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
---
Reproduced on x86_64 under KASAN_INLINE on v7.3-rc2, with an initramfs
that does the two writes above from init and then waits for the deferred
free. Without the patch the second write reports the slab-use-after-free
quoted above; with it there is no report, and each rejected clock leaves
its own entry in tracing/error_log instead of only the first attempt
getting that far.

Same kernel and initramfs, selftests/ftrace test.d/trigger before and
after: 45 results, identical item by item (32 passed, 3 failed, 2
unresolved, 8 unsupported). The failures and the unresolved results are
there without the patch as well.

 kernel/trace/trace_events_hist.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 963e0d6b61fd..6c628415468a 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -6643,12 +6643,6 @@ static int hist_register_trigger(char *glob,
 		data->cmd_ops = cmd_ops;
 	}
 
-	if (data->cmd_ops->init) {
-		ret = data->cmd_ops->init(data);
-		if (ret < 0)
-			goto out;
-	}
-
 	if (hist_data->enable_timestamps) {
 		char *clock = hist_data->attrs->clock;
 
@@ -6661,6 +6655,15 @@ static int hist_register_trigger(char *glob,
 		tracing_set_filter_buffering(file->tr, true);
 	}
 
+	if (data->cmd_ops->init) {
+		ret = data->cmd_ops->init(data);
+		if (ret < 0) {
+			if (hist_data->enable_timestamps)
+				tracing_set_filter_buffering(file->tr, false);
+			goto out;
+		}
+	}
+
 	if (named_data) {
 		remove_hist_vars(hist_data);
 		destroy_hist_data(hist_data);

base-commit: df2908090cda368b01ff43709f51890076c56157
-- 
2.53.0

Re: [PATCH] tracing: hist: set the trace clock before registering the trigger

[sashiko-bot]

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

Pre-existing issues:
- [High] Use-After-Free list corruption if `event_hist_trigger_init` fails during named trigger initialization.
- [High] Use-After-Free list corruption because a newly created named trigger remains on the global `named_triggers` list if `hist_trigger_enable()` fails.
--

commit 1e5ea6c77dc8e3a10275a88758d5ef5a8d54be44
Author: Donggeun Yoo <donggeunyoo.kernel@gmail.com>

tracing: hist: set the trace clock before registering the trigger

hist_register_trigger() puts the trigger on the global named_triggers
list in cmd_ops->init(), and only then sets the trace clock.
The clock string is not checked anywhere before that call, so a named
trigger using common_timestamp with an unknown clock fails after it has
already become findable.

> diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
> index 963e0d6b61fdf..6c628415468a6 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -6643,12 +6643,6 @@ static int hist_register_trigger(char *glob,
>  		data->cmd_ops = cmd_ops;
>  	}
>  
> -	if (data->cmd_ops->init) {
> -		ret = data->cmd_ops->init(data);
> -		if (ret < 0)
> -			goto out;
> -	}
> -

[ ... ]

> @@ -6661,6 +6655,15 @@ static int hist_register_trigger(char *glob,
>  		tracing_set_filter_buffering(file->tr, true);
>  	}
>  
> +	if (data->cmd_ops->init) {
> +		ret = data->cmd_ops->init(data);
> +		if (ret < 0) {
> +			if (hist_data->enable_timestamps)
> +				tracing_set_filter_buffering(file->tr, false);
> +			goto out;
> +		}
> +	}
> +
>  	if (named_data) {
>  		remove_hist_vars(hist_data);
>  		destroy_hist_data(hist_data);

While reviewing this patch, I noticed a couple of pre-existing issues
related to how named triggers are handled during initialization and error 
paths in this same file.

kernel/trace/trace_events_hist.c:event_hist_trigger_named_init() {
    ...
	save_named_trigger(data->named_data->name, data);

	ret = event_hist_trigger_init(data->named_data);
	if (ret < 0) {
		kfree(data->cmd_ops);
		data->cmd_ops = &trigger_hist_cmd;
	}

	return ret;
}

[Severity: High]
This isn't a bug introduced by this patch, but does this error path leave 
the new trigger on the global named_triggers list? 

If event_hist_trigger_init() fails, the trigger is never removed from the 
list before the function returns the error. The caller then propagates 
this error, eventually calling trigger_data_free() which frees the 
structure. Can this lead to a Use-After-Free list corruption when the 
global named_triggers list is accessed later?

Also, further down in the file:

kernel/trace/trace_events_hist.c:event_hist_trigger_parse() {
    ...
	ret = event_trigger_register(cmd_ops, file, glob, trigger_data);
	if (ret < 0)
		goto out_free;

	ret = hist_trigger_enable(trigger_data, file);
	if (ret)
		goto out_unreg;
    ...
 out_unreg:
	event_trigger_unregister(cmd_ops, file, glob+1, trigger_data);
 out_free:
	remove_hist_vars(hist_data);

	trigger_data_free(trigger_data);
    ...
}

[Severity: High]
This is a pre-existing issue, but does this error path also result in 
Use-After-Free list corruption?

If hist_trigger_enable() fails, it drops the trigger from the local file 
list but then we jump to out_unreg. Because the trigger is no longer in 
file->triggers, event_trigger_unregister() won't find it and skips calling 
cmd_ops->free() (which would normally call del_named_trigger()). 

The code then falls through to trigger_data_free(). Does this manually 
free the memory without ever calling del_named_trigger(), leaving a freed 
node on the global named_triggers list?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907091415.554535-1-donggeunyoo.kernel@gmail.com?part=1

Re: [PATCH] tracing: hist: set the trace clock before registering the trigger

[Donggeun Yoo]

On Mon, Sep 07, 2026 at 09:29:43AM +0000, sashiko-bot@kernel.org wrote:
> This isn't a bug introduced by this patch, but does this error path leave
> the new trigger on the global named_triggers list?
>
> If event_hist_trigger_init() fails, the trigger is never removed from the
> list before the function returns the error. The caller then propagates
> this error, eventually calling trigger_data_free() which frees the
> structure. Can this lead to a Use-After-Free list corruption when the
> global named_triggers list is accessed later?

Yes, and so does the second one. Both end in the same read this patch is
about, and neither is fixed by it.

event_hist_trigger_named_init() publishes the trigger before the only step
that can fail:

	data->ref++;

	save_named_trigger(data->named_data->name, data);

	ret = event_hist_trigger_init(data->named_data);

event_hist_trigger_init() can only fail on alloc_hist_pad() returning
-ENOMEM. Forcing that, with this patch applied:

  BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
  Read of size 8 at addr ffff888009346860 by task init/1
   find_named_trigger+0xac/0xc0
   hist_register_trigger+0xc1/0xa00
   event_hist_trigger_parse+0x3146/0x6af0
   event_trigger_write+0xce/0x160
  Freed by task 67:
   kfree+0x154/0x420
   trigger_kthread_fn+0xfd/0x160

> If hist_trigger_enable() fails, it drops the trigger from the local file
> list but then we jump to out_unreg. Because the trigger is no longer in
> file->triggers, event_trigger_unregister() won't find it and skips calling
> cmd_ops->free() (which would normally call del_named_trigger()).
>
> The code then falls through to trigger_data_free(). Does this manually
> free the memory without ever calling del_named_trigger(), leaving a freed
> node on the global named_triggers list?

Yes. hist_trigger_enable() removes the trigger from file->triggers before
returning the error, so the list walk in hist_unregister_trigger() matches
nothing, test stays NULL, cmd_ops->free() is not called and
del_named_trigger() never runs. Forcing trace_event_enable_disable() to
fail for a named trigger:

  BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0
  Read of size 8 at addr ffff8880091d3160 by task init/1
   find_named_trigger+0xac/0xc0
   hist_register_trigger+0xc1/0xa00
   event_hist_trigger_parse+0x3146/0x6af0
   event_trigger_write+0xce/0x160
  Freed by task 69:
   kfree+0x154/0x420
   trigger_kthread_fn+0xfd/0x160

A control run with no injected failure is clean on both.

Both fixed here:

  https://lore.kernel.org/linux-trace-kernel/20260907124420.607097-1-donggeunyoo.kernel@gmail.com/