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
