CVE-2026-90002: ftrace: Take trace_array reference before accessing its ftrace_ops
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Take tracearray reference before accessing its ftraceops
The trace instance files setftracefilter and setftracenotrace was updated to work with specific trace instances (tracearrays). The issue is that when these files are opened, there is a small race window where it will use the ftraceops from the inode->private pointer to get a reference to the tracearray and then take its reference. The problem is that the ftraceops itself could be freed. If the rmdir on the instance happens at the same time the setftracefilter file is opened, the rmdir could have also freed the ftraceops and referencing it will cause a use-after-free bug and crash the kernel.
Instead, pass in the tracearray as the file private data (NULL for the top level instance), and then pass both the tracearray and the ftraceops to the ftraceregexopen() function. If the tracearray is NULL, then it just uses the ftraceops without the need to take its reference (like normal). If the ftraceops is NULL, that is only the case for the top level instance and the globalops can be used.
This allows the tracearray to have its reference incremented before touching the ftraceops that could also be freed when the instance is.
Affected Software
Event History
Frequently Asked Questions
Which tracing setup is exposed to this race?
The race concerns specific ftrace trace instances and their set_ftrace_filter or set_ftrace_notrace files. The top-level tracing instance follows a separate path using the global ftrace operations.
What condition is required to trigger the use-after-free?
A set_ftrace_filter or set_ftrace_notrace file for a trace instance must be opened while that same instance is being removed with rmdir. The removal can free the instance's ftrace_ops before the open path obtains the trace_array reference, potentially causing a kernel crash.