Linux Coresight ETR Use-After-Free Patch CVE-2025-68376

A subtle logic error in the Linux kernel’s Coresight ETR driver has been identified and fixed, and the fix has been assigned CVE-2025-68376. The bug is a classic use‑after‑free that can occur when the Embedded Trace Relay (ETR) buffer is resized while the device is active in sysfs mode; under those conditions a pointer used by the running ETR can remain tied to freed memory, producing memory corruption and potential instability. Kernel maintainers pushed a small, surgical change to the coresight TMC‑ETR code to prevent the driver from freeing the active buffer when the tracer is enabled in CS_MODE_SYSFS, eliminating the window that produced the use‑after‑free.

Background / Overview​

The Linux Coresight subsystem provides hardware tracing support on ARM and other architectures. One of its sink devices, ETR (Embedded Trace Relay), exposes a sysfs buffer interface that userspace can resize and enable or disable. Internally this code manages two buffer pointers: the sysfs buffer that user interactions manipulate, and the active etr buffer used by the hardware while tracing is running.
The vulnerability arises from a race in buffer management. If a user enlarges or otherwise changes the ETR sysfs buffer size and re-enables the sink without first ensuring the ETR’s internal buffer pointer is updated, the driver can free the old memory while the ETR is still referencing it — a textbook use‑after‑free. The practical result is memory corruption inside kernel space which may cause crashes, undefined behavior, or other forms of instability.
A compact patch was submitted and accepted that alters the logic around buffer replacement: when the coresight device is running in the CS_MODE_SYSFS mode, the driver will no longer release the old sysfs buffer or swap the pointers while the ETR remains enabled. The patch prevents immediate freeing of memory in the live tracing path and thereby stops the use‑after‑free window.

---

Why this matters: tracing vs general surface area​

Hardware tracing facilities like Coresight are typically exercised by platform bring‑up, performance engineers, vendors, and advanced debugging tools; they are not commonly exposed to arbitrary internet‑facing workloads. That reduces the immediate risk profile for widespread remote exploitation. However, there are several reasons this fix is important:

• Kernel memory corruption is high‑risk. Use‑after‑free bugs in kernel code can lead to crashes, privilege escalation, or other severe outcomes when triggered in privileged contexts.
• Tracing is used in many development and performance scenarios. Even though Coresight is not a consumer‑facing API for most systems, servers, development boards, and embedded devices frequently enable hardware tracing during diagnostics. A misbehaving tracer can destabilize such systems during critical operations.
• Device firmware, vendor kernels, and distribution patches lag. Embedded and vendor kernels may take extra time to receive fixes. Systems running older kernels or long‑term support branches may remain vulnerable until downstream vendors merge the patch.

For these reasons, while the bug’s exploitability is constrained by access to the tracing sysfs interfaces, it still warrants prompt attention on systems where hardware tracing is used or where vendor kernels bundle Coresight drivers.

---

Technical analysis: what went wrong​

The root cause is straightforward and visible in the driver logic for sysfs buffer allocation and replacement. The driver maintains:

• sysfs_buf — a pointer used to hold the sysfs-exposed buffer that users may read and resize via /sys/bus/coresight/devices/…/buffer_size and related attributes.
• etr_buf — the actual buffer pointer used by the ETR sink while tracing is enabled.

The sequence that produced the bug:

1. The user (or a tool) changes the sysfs buffer size while the device is active in sysfs mode.
2. The driver allocates a fresh buffer (buf_new) to satisfy the new size and sets sysfs_buf to point at buf_new.
3. The driver frees the old allocation (buf_old).
4. However, etr_buf — the buffer currently used by the running ETR — still points to buf_old because it was not updated.
5. The running ETR continues to write into memory that has just been freed, creating a use‑after‑free.

The accepted patch adds a guard to the buffer‑replacement flow: when the Coresight device is in CS_MODE_SYSFS (the mode where the ETR is actively using the sysfs buffer), the code now skips releasing and replacing the old sysfs buffer. In practice the driver checks the device mode before freeing buf_old and aborts the replacement if the device is in that active mode. That prevents etr_buf from being left dangling.
This is a pragmatic fix: it avoids changing the broader lifecycle semantics of the buffers or adding complicated synchronization. Instead it ensures the code never frees memory that might still be referenced by active hardware tracing.

The patch, in plain language​

• Add a mode check right before the code path that updates sysfs_buf and releases the previous allocation.
• If the device is running in CS_MODE_SYSFS, do not replace sysfs_buf and do not free buf_old.
• Otherwise, proceed with the allocation, pointer swap, and free as before.

This minimal, targeted change reduces risk and preserves existing behavior for non‑active modes while closing the use‑after‑free hole.

---

Affected code path and how to detect exposure​

The vulnerable logic resides in the coresight TMC‑ETR driver, specifically the function responsible for obtaining and managing the sysfs buffer (commonly referenced as tmc_etr_get_sysfs_buffer or similar). Detection and exposure depend on three main conditions:

• The device has a Coresight ETR sink driver present (drivers/hwtracing/coresight/coresight‑tmc‑etr.c).
• The sink is being used in CS_MODE_SYSFS, meaning the kernel and userspace have enabled the sink and are using the sysfs buffer interface rather than, for example, perf mode.
• The buffer size is being changed while the sink is enabled, and the driver performs the replace/free sequence that the patch addresses.

To check whether a system exposes the ETR sysfs interface:

• Inspect /sys/bus/coresight/devices/ for entries such as tmc_etr0 or similar.
• Read /sys/bus/coresight/devices/tmc_etr0/buffer_size to see the current size and try the enable attributes:
  • echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink
  • echo 1 > /sys/bus/coresight/devices/etmX/enable_source

If these sysfs nodes exist and are writable by administrative users, the system can resize and enable the ETR buffer from userspace — the very sequence that could trigger the use‑after‑free if the kernel lacks the fix.

---

Exploitability and impact​

• Remote exploitation: unlikely. The sysfs interfaces controlling Coresight are local kernel sysfs nodes; remote exploitation would require remote code execution or access to a local privileged account that can interact with /sys. There is no indication that this vulnerability is remotely exploitable without local access.
• Local abuse: plausible. A local user with privileges to interact with Coresight sysfs attributes (typically root) could trigger the vulnerable sequence. On development boards, CI runners, or vendor devices where tracing is exposed to a build user or an unprivileged maintenance user this may be a practical attack vector.
• Severity: moderate-to-high in context. Kernel memory corruption is always serious because of the potential for system crashes or privilege escalation. The practical severity depends on who can reach the sysfs interface and whether the system uses ETR tracing.
• No known public exploit at time of disclosure. At the time the fix was committed, there were no credible public exploit reports. Nevertheless, the type of bug and the possibility for kernel memory corruption justify timely patching.

---

Timeline and fix deployment​

The fix was prepared and submitted as a small patch to the Linux kernel Coresight driver. The patch was later merged into the upstream kernel tree and included in stable backports on the usual kernel maintenance channels. Distribution kernels and vendor trees will need to merge the change into their branches.
Key practical points for administrators:

1. The fix is present in upstream kernel maintenance branches and in newer kernel releases after the merge point.
2. Downstream distributions may need additional time to pick up and test the change in their packaging pipelines before releasing updates to users.
3. Embedded vendors and SoC suppliers who maintain vendor kernels should be contacted or monitored for vendor advisories, because many Coresight consumers are on custom kernels that lag upstream.

Systems that are not using Coresight ETR or that have ETR disabled via kernel configuration or platform device trees are not exposed in practice. Nonetheless, a conservative approach is to treat all systems with the coresight‑tmc‑etr driver as potentially affected until the kernel package is updated.

---

Recommended actions: patching, detection, and mitigations​

• Priority: systems that run hardware tracing (development boards, CI nodes, performance workstations, embedded devices with active tracing) should be prioritized for updates.
• Patch / Update: apply the upstream kernel patch or upgrade to a kernel release that contains the fix. For distribution kernels, apply the vendor-supplied security update as soon as it becomes available.
• Backporting: for critical embedded systems, consider backporting the minimal patch into the vendor kernel tree. The change is small and self‑contained, which reduces the risk of backport conflicts.
• Temporary mitigation: if an immediate kernel update is not possible and the system exposes Coresight sysfs nodes:
  • Disable the ETR sink in sysfs (echo 0 > …/enable_sink) before adjusting buffer sizes.
  • Restrict access to Coresight sysfs attributes to trusted administrators only (enforce tighter udev permissions or ACLs).
  • Avoid changing buffer sizes while tracing is enabled.
• Detection: create a simple audit rule or system check that alerts when /sys/bus/coresight/devices/ contains tmc_etr nodes and when enable_sink or buffer_size attributes are changed. Monitoring kernel dmesg for coresight‑related oopses can also reveal attempts to trigger kernel memory corruption.

Practical commands to check tracing state:

1. List Coresight devices:
   • ls /sys/bus/coresight/devices/
2. Check ETR devices:
   • cat /sys/bus/coresight/devices/tmc_etr/buffer_size
3. Inspect enable state:
   • cat /sys/bus/coresight/devices/tmc_etr/enable_sink

Administrators can use these steps to identify systems that host the potentially vulnerable interfaces and to protect them until a kernel update is installed.

---

What the patch does and why it’s a safe change​

The fix is intentionally conservative: rather than rework the buffer lifecycle or add elaborate synchronization between hardware state and sysfs allocation, the patch simply refuses to free or swap the sysfs buffer while the device is running in CS_MODE_SYSFS. This approach avoids the immediate hazard — freeing memory that is still referenced by live hardware — without changing user‑observable behavior for the majority of cases.
Advantages of this approach:

• Minimal code churn. Small changes reduce the risk of regression in a complex, timing‑sensitive driver.
• Simple and verifiable. The guard is easy to audit and reason about.
• Low performance impact. The change only affects the corner case of resizing the sysfs buffer while the sink is active.

Potential limitations and reasons to track follow‑on work:

• The patch prevents buffer replacement while ETR is enabled in sysfs mode but does not attempt to atomically swap buffers with synchronization to the hardware. Some workflows might want a safe, atomic resize that is still possible while running; that would require more elaborate coordination with the hardware or a transient shutdown of the sink during resize operations.
• There may be users or tools that expect buffer resizing to proceed regardless of enable state; they will need to disable the sink before resizing in the current semantics.

Overall the chosen fix prioritizes correctness and safety over convenience, which is appropriate for kernel code that interfaces with hardware and performs privileged memory operations.

---

Who should care and why​

• Kernel maintainers and device vendors: should merge and push the fix through vendor kernels, especially for platforms where Coresight is commonly used (development boards, SoC vendors, mobile OEM kernels).
• Embedded device integrators: may need to backport the patch to long‑term maintenance branches or vendor kernels to avoid instability in devices that use tracing for telemetry or debugging.
• Platform engineers and performance teams: who rely on hardware tracing for profiling and debugging must update their host and target kernels or adopt the mitigation steps to avoid triggering the issue during diagnostic workflows.
• Security teams: should treat the issue like any kernel memory corruption vulnerability: track vendor advisories, schedule kernel updates for affected systems, and reduce exposure for interfaces that allow local manipulation of kernel tracing state.

For typical end users on desktop or server installations that do not enable hardware tracing, the immediate practical risk is low. For any account with the ability to write to sysfs (typically root), the potential to trigger kernel memory corruption is present until the kernel is patched.

---

Verifiability and remaining uncertainties​

The fix was implemented as a targeted driver change in the coresight TMC‑ETR code and merged into upstream kernel trees. Multiple independent vulnerability trackers and the kernel patch mailing list documented the issue and the subsequent patch.
A few caveats and items to watch:

• Distribution timelines vary. Even though the patch is upstream, downstream kernels in distributions or vendor trees may not include the fix immediately. Confirm vendor advisories and kernel package version numbers for your platform.
• The exact affected kernel version ranges and stable backports depend on merge points and backport decisions; if precise version gating is required for compliance, confirm with the vendor or check the exact commit hashes in your kernel tree.
• There is no public indication of a working exploit chain beyond the use‑after‑free itself; exploitability in the wild is not reported at the time of this fix. However, the class of bug (kernel UAF) justifies patching in sensitive environments.

These points underscore the importance of verifying the presence of the fix in your exact kernel build or vendor package rather than relying solely on generalized version guidelines.

---

Final assessment and recommendations​

CVE‑2025‑68376 addresses a correctable and potentially dangerous kernel memory corruption condition in the Coresight ETR driver that occurs when the sysfs buffer is changed while the sink is enabled. The remedial patch is small, well‑scoped, and reduces the kernel’s attack surface by preventing freeing of an active buffer.
Actionable guidance:

1. Audit systems for presence of ETR sysfs devices and prioritize systems where hardware tracing is used.
2. Install vendor or upstream kernel updates that include the coresight ETR fix as soon as they are available.
3. Mitigate by disabling ETR tracing or restricting access to Coresight sysfs nodes until the update is applied.
4. For embedded vendors, backport the patch into long‑term maintenance kernels and test thoroughly on hardware that uses Coresight.

This is an example where a focused, minimal change to kernel logic removes a clear correctness bug while keeping behavioral impact low. For environments that rely on hardware tracing, the fix should be treated as a routine kernel security update and applied in the next maintenance cycle to avoid stability surprises during debugging or profiling tasks.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center