CVE-2026-97933: tracing: Take trace_array reference when opening a tracer options file
In the Linux kernel, the following vulnerability has been resolved:
tracing: Take tracearray reference when opening a tracer options file
When a tracer option file is opened, it is passed a descriptor that points to an element on the tracearray's topts array. This element has information to find the trace array and other information. It uses this element to take a reference of the tracearray so that the tracearray does not get removed while this file is opened.
Unfortunately, there's a race condition where the element itself could be freed by the removal of the instance the tracearray represents causing a use-after-free as this element that is used to find the tracearray to increment its reference counter is also freed when the instance is removed.
To solve this, add a tracearraytraceroptionsget() helper function that will take the address of the element that is passed to the open function by the inode->iprivate pointer and search all the tracearrays under a lock to find the one that the element's address is in the range of the tracearrays topts array elements. When a match happens, that tracearray's reference would be increased.
Note, there's a race where if an admin was deleting and creating trace instances at the same time and the memory of the old tracearray's array matched the memory of the new tracearray that it could in theory open the option from the wrong trace array. But we do not care because it would be stupid to perform that kind of action. As long as the only thing that can happen is that the option from the wrong trace array is used and doesn't crash the kernel it will only make the user confused. But if they are doing something stupid like this, they are already confused, so no harm done.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this race?
Linux kernel systems using tracing are exposed when a tracer option file can be opened while the trace-array instance associated with that option is being removed.
What sequence causes the use-after-free?
A tracer option file open receives a descriptor pointing into the trace array's options array. If the corresponding instance is removed before the open path obtains a trace-array reference, that descriptor can already have been freed and may be dereferenced.
How does the resolved implementation prevent the issue?
It searches the trace arrays under a lock to identify which trace array owns the options-array element supplied through inode->i_private. Once a match is found, it increments that trace array's reference before it can be removed.