[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