On Fri, Aug 28, 2026 at 10:39:01PM -0400, Steven Rostedt wrote: > From: Steven Rostedt <[email protected]> > > The trace instance files set_ftrace_filter and set_ftrace_notrace was > updated to work with specific trace instances (trace_arrays). The issue is > that when these files are opened, there is a small race window where it > will use the ftrace_ops from the inode->private pointer to get a reference > to the trace_array and then take its reference. The problem is that the > ftrace_ops itself could be freed. If the rmdir on the instance happens at > the same time the set_ftrace_filter file is opened, the rmdir could have > also freed the ftrace_ops and referencing it will cause a use-after-free > bug and crash the kernel. > > Instead, pass in the trace_array as the file private data (NULL for the > top level instance), and then pass both the trace_array and the ftrace_ops > to the ftrace_regex_open() function. If the trace_array is NULL, then it > just uses the ftrace_ops without the need to take its reference (like > normal). If the ftrace_ops is NULL, that is only the case for the top > level instance and the global_ops can be used. > > This allows the trace_array to have its reference incremented before > touching the ftrace_ops that could also be freed when the instance is. > > Cc: [email protected] > Fixes: 591dffdade9f0 ("ftrace: Allow for function tracing instance to filter > functions") > Reported-by: Breno Leitao <[email protected]> > Closes: https://lore.kernel.org/all/[email protected]/ > Signed-off-by: Steven Rostedt <[email protected]>
Tested-by: Breno Leitao <[email protected]> Thanks Steven for the quick fix, --breno
