Re: [PATCH v2] ftrace: Take trace_array reference before accessing its ftrace_ops

[Breno Leitao <leitao@debian.org>]

On Fri, Aug 28, 2026 at 10:39:01PM -0400, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> 
> 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: stable@vger.kernel.org
> Fixes: 591dffdade9f0 ("ftrace: Allow for function tracing instance to filter functions")
> Reported-by: Breno Leitao <leitao@debian.org>
> Closes: https://lore.kernel.org/all/apGORjltZgAiAYHT@gmail.com/
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Tested-by: Breno Leitao <leitao@debian.org>

Thanks Steven for the quick fix,
--breno