[BUG] tracing: trigger filter use-after-free in set_trigger_filter() ENOMEM path

[BUG] tracing: trigger filter use-after-free in set_trigger_filter() ENOMEM path

[Guikun Yang]

Hi Steve, Masami,

set_trigger_filter() (kernel/trace/trace_events_trigger.c) violates RCU
publishing rules in its ENOMEM path, leading to a possible
use-after-free of struct event_filter.

The normal path is careful:

	tmp = rcu_access_pointer(data->filter);
	rcu_assign_pointer(data->filter, filter);
	if (tmp) {
		/*
		 * Make sure the call is done with the filter.
		 * ...
		 */
		if (system_state != SYSTEM_BOOTING)
			tracepoint_synchronize_unregister();
		free_event_filter(tmp);
	}

The old filter is freed only after tracepoint_synchronize_unregister(),
because trigger handlers read it under rcu_read_lock_sched() via
rcu_dereference_sched(data->filter) in event_triggers_call().

But the tail of the same function is not:

	kfree(data->filter_str);
	data->filter_str = NULL;

	if (filter_str) {
		data->filter_str = kstrdup(filter_str, GFP_KERNEL);
		if (!data->filter_str) {
			free_event_filter(rcu_access_pointer(data->filter));
			data->filter = NULL;
			ret = -ENOMEM;
		}
	}

At this point data->filter is the freshly published "filter" (from the
rcu_assign_pointer above).  When the kstrdup of the filter string fails
under memory pressure, the just-published filter is freed immediately,
without any grace period.  A concurrent event_triggers_call() on
another CPU can have already dereferenced data->filter (this filter)
under rcu_read_lock_sched() and be walking the preds when the kfree
lands — a use-after-free.

Sequence:

    T1 (tracefs write, holds event_mutex)      T2 (tracepoint fires)
    -----------------------------------------  -------------------------------
    create_event_filter(...) -> F_new
    rcu_assign_pointer(data->filter, F_new)
                                               data->filter deref -> F_new
                                               filter_match_preds(F_new)...
    kstrdup(filter_str) fails
    free_event_filter(F_new)   /* no sync! */  ... still using F_new

The write side holds event_mutex, but the trigger execution side does
not take that mutex; the only protection for the filter lifetime is the
RCU grace period, which this path skips.

Trigger conditions: an admin writes a trigger with an "if" filter
while the target event fires at high rate (e.g. sched_switch,
irq handlers), and the kstrdup fails (GFP_KERNEL allocation under
memory pressure).  The failing allocation is easy to hit repeatedly
via a memory-hungry cgroup.  The freed filter's preds array is
then read by filter_match_preds().

Fix: either free the new filter before publishing (i.e., don't
rcu_assign_pointer until the filter_str copy succeeded), or perform
tracepoint_synchronize_unregister() before free_event_filter() in the
ENOMEM path, mirroring the normal path.  The first variant is
cheaper: move the kstrdup above the "assign:" label and release the
pointer only after the string copy succeeded.

I found this by code inspection.  Checked against 7.3.0-rc7 and
linux-next (2026-10-24): both are unchanged.  syzbot has no matching
report (its trigger coverage focuses on counting/snapshot triggers,
not on the ENOMEM path of filter assignment), and I found no prior
report on lore/marc.

Best,
Guikun Yang

Re: [BUG] tracing: trigger filter use-after-free in set_trigger_filter() ENOMEM path

[Steven Rostedt]

On Sat, 24 Oct 2026 22:48:16 +0800
Guikun Yang <yangguikun19@qq.com> wrote:

> Fix: either free the new filter before publishing (i.e., don't
> rcu_assign_pointer until the filter_str copy succeeded), or perform
> tracepoint_synchronize_unregister() before free_event_filter() in the
> ENOMEM path, mirroring the normal path.  The first variant is
> cheaper: move the kstrdup above the "assign:" label and release the
> pointer only after the string copy succeeded.

Note, the entire trigger code needs a rewrite. Something I'm looking at
doing when I get time.

This is a bug but one that would be very hard to hit as it would
require and admin to enable a trigger with a filter during major memory
pressure.

That said, the simplest fix is to simply copy the filter_str at near
the start and use that.

That is, something like this (not even compiled tested):

diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
index 4d2fde996c0f..1a6ea4261066 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -1195,6 +1195,7 @@ int set_trigger_filter(char *filter_str,
 {
 	struct event_trigger_data *data = trigger_data;
 	struct event_filter *filter = NULL, *tmp;
+	char *str __free(kfree) = NULL;
 	int ret = -EINVAL;
 	char *s;
 
@@ -1209,9 +1210,13 @@ int set_trigger_filter(char *filter_str,
 	if (!filter_str)
 		return ret;
 
+	str = kstrdup(filter_str, GFP_KERNEL);
+	if (!str)
+		return -ENOMEM;
+
 	/* The filter is for the 'trigger' event, not the triggered event */
 	ret = create_event_filter(file->tr, file->event_call,
-				  filter_str, true, &filter);
+				  str, true, &filter);
 
 	/* Only enabled set_str for error handling */
 	if (filter) {
@@ -1243,14 +1248,9 @@ int set_trigger_filter(char *filter_str,
 	kfree(data->filter_str);
 	data->filter_str = NULL;
 
-	if (filter_str) {
-		data->filter_str = kstrdup(filter_str, GFP_KERNEL);
-		if (!data->filter_str) {
-			free_event_filter(rcu_access_pointer(data->filter));
-			data->filter = NULL;
-			ret = -ENOMEM;
-		}
-	}
+	if (str)
+		data->filter_str = no_free_ptr(str);
+
 	return ret;
 }