CVE-2026-97933

tracing: Take trace_array reference when opening a tracer options file

N/A
Published: September 25, 2026 at 10:22 AM UTC
Updated: October 21, 2026 at 01:21 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: tracing: Take trace_array 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 trace_array'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 trace_array so that the trace_array 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 trace_array represents causing a use-after-free as this element that is used to find the trace_array to increment its reference counter is also freed when the instance is removed. To solve this, add a trace_array_tracer_options_get() helper function that will take the address of the element that is passed to the open function by the inode->i_private pointer and search all the trace_arrays under a lock to find the one that the element's address is in the range of the trace_arrays topts array elements. When a match happens, that trace_array'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 trace_array's array matched the memory of the new trace_array 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

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

2617afde0c3db285778734b0ccad9a55b4f9cda25.10.1975.15.1335.4.257586787a0331aa2d7d244e9c4400d2a73295b0cf06.1.556.5.56.67e2cfbd2d3c86afcd5c26b5c4b1dd251f63c5838952e477f908048145a5eb2ed3d431d9efc1e1073b3183f5f05cd867f5c17122773ca5aa8d07b51afbf38c1d29f8bfe9631b62a67f8dd1b8f7efb7139
Vendor states this is fixed in b2890064a12efbeb3b3c093e69e9010dd244c881 (fixed)
Vendor states this is fixed in b2fb87d29ffb3a7a9ccc5acf12898ecb80587427 (fixed)
Vendor states this is fixed in ed0aff60f83a9bdc2f6556376ac79c96b3ce7e80 (fixed)
Affected range stops below 5.11, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.16, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.5, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.12.112 (unaffected)
Vendor states this is fixed in 6.18.57 (unaffected)
Affected range stops below 6.2, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.6 (unaffected)
Vendor states this is fixed in 6.6.160 (unaffected)
Vendor states this is fixed in 7.2.7 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc3 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card