CVE-2026-31541: tracing: Fix trace_marker copy link list updates
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix tracemarker copy link list updates
When the "copytracemarker" option is enabled for an instance, anything written into /sys/kernel/tracing/tracemarker is also copied into that instances buffer. When the option is set, that instance's tracearray descriptor is added to the markercopies link list. This list is protected by RCU, as all iterations uses an RCU protected list traversal.
When the instance is deleted, all the flags that were enabled are cleared. This also clears the copytracemarker flag and removes the tracearray descriptor from the list.
The issue is after the flags are called, a direct call to updatemarkertrace() is performed to clear the flag. This function returns true if the state of the flag changed and false otherwise. If it returns true here, synchronizercu() is called to make sure all readers see that its removed from the list.
But since the flag was already cleared, the state does not change and the synchronization is never called, leaving a possible UAF bug.
Move the clearing of all flags below the updating of the copytracemarker option which then makes sure the synchronization is performed.
Also use the flag for checking the state in updatemarkertrace() instead of looking at if the list is empty.
Affected Software
Remediation
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems are exposed when a tracing instance has the "copy_trace_marker" option enabled, causing writes to /sys/kernel/tracing/trace_marker to be copied into that instance's buffer. The vulnerable condition occurs when that tracing instance is deleted.
What access does an attacker need?
The CVSS vector indicates local access with low privileges is required, and no user interaction is needed. Exploitation also depends on reaching the tracing configuration and instance-deletion path associated with the enabled option.
How can I determine whether the relevant configuration is in use?
Check whether tracing instances have the "copy_trace_marker" option enabled and whether the system permits writes to /sys/kernel/tracing/trace_marker. The issue is specifically tied to removal of an instance from the internal marker-copy list during instance deletion.
What should I do if I cannot patch immediately?
Disable the "copy_trace_marker" option for tracing instances and limit local low-privileged access to tracing controls and /sys/kernel/tracing/trace_marker where possible. A patch is available.