In the Linux kernel, the following vulnerability has been resolved:
ftrace: Take trace_array reference before accessing its ftrace_ops
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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The UAF is reached only by a local open() of an instance set_ftrace_filter/set_ftrace_notrace racing rmdir of that tracing instance under /sys/kernel/tracing/instances; there is no network or adjacent-protocol path into ftrace_filter_open().
AC:L - The attacker drives both sides: mkdir an instance, open its filter file on one thread, and rmdir it on another. instance_rmdir drops inode locks and kfree()s ftrace_ops before unlinking the files, so the race is retryable with no condition outside attacker control.
PR:L - ftrace_regex_open()/instance mkdir/rmdir check only LOCKDOWN_TRACEFS (off by default) and DAC, with no capable() call. Android/Perfetto, ChromeOS, and distro tracing-group gid= mounts routinely grant unprivileged users write on /sys/kernel/tracing/instances.
UI:N - The attacker performs mkdir, concurrent open of set_ftrace_filter/set_ftrace_notrace, and rmdir entirely from their own threads; no victim mount, click, or other-user action is required.
S:U - The use-after-free is of a kmalloc'd struct ftrace_ops in the host kernel heap; any privilege escalation stays within the kernel's own security authority and does not cross a VM, IOMMU, or sandbox boundary.
C:H - This is a use-after-free of heap-allocated ftrace_ops: open() reads ops->private, ops->flags, and ops->func_hash from the freed object, so after slab reclaim/spray those fields become attacker-controlled and yield an arbitrary kernel read.
I:H - ftrace_ops_init() writes flags, func_hash, and a mutex into the freed object and later mutex_lock()s ops->func_hash->regex_lock; with spray this is an arbitrary-write primitive, and ftrace_ops also carries hijackable function pointers (func, ops_func).
A:H - Dereferencing the freed ftrace_ops (ops->private, flags, func_hash) on the open-versus-rmdir race reliably oopses or panics the kernel, as described in the fix, and can be re-triggered by repeating instance create/open/rmdir.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The UAF is reached only by a local open() of an instance set_ftrace_filter/set_ftrace_notrace racing rmdir of that tracing instance under /sys/kernel/tracing/instances; there is no network or adjacent-protocol path into ftrace_filter_open().
AC:L - The attacker drives both sides: mkdir an instance, open its filter file on one thread, and rmdir it on another. instance_rmdir drops inode locks and kfree()s ftrace_ops before unlinking the files, so the race is retryable with no condition outside attacker control.
PR:L - ftrace_regex_open()/instance mkdir/rmdir check only LOCKDOWN_TRACEFS (off by default) and DAC, with no capable() call. Android/Perfetto, ChromeOS, and distro tracing-group gid= mounts routinely grant unprivileged users write on /sys/kernel/tracing/instances.
UI:N - The attacker performs mkdir, concurrent open of set_ftrace_filter/set_ftrace_notrace, and rmdir entirely from their own threads; no victim mount, click, or other-user action is required.
S:U - The use-after-free is of a kmalloc'd struct ftrace_ops in the host kernel heap; any privilege escalation stays within the kernel's own security authority and does not cross a VM, IOMMU, or sandbox boundary.
C:H - This is a use-after-free of heap-allocated ftrace_ops: open() reads ops->private, ops->flags, and ops->func_hash from the freed object, so after slab reclaim/spray those fields become attacker-controlled and yield an arbitrary kernel read.
I:H - ftrace_ops_init() writes flags, func_hash, and a mutex into the freed object and later mutex_lock()s ops->func_hash->regex_lock; with spray this is an arbitrary-write primitive, and ftrace_ops also carries hijackable function pointers (func, ops_func).
A:H - Dereferencing the freed ftrace_ops (ops->private, flags, func_hash) on the open-versus-rmdir race reliably oopses or panics the kernel, as described in the fix, and can be re-triggered by repeating instance create/open/rmdir.
CVSS 3.1