CVE-2026-46272

What it actually does

CVE-2026-46272 is a race condition in the Linux kernel CoreSight TMC-ETR tracing driver where sysfs-based tracing and perf-based tracing can concurrently attempt to enable the same Embedded Trace Router hardware buffer. Because sysfs mode performs buffer allocation and hardware enablement in separate critical sections, perf mode can initialize drvdata->etr_buf in between those operations. A later sysfs enable path may then encounter an unexpected initialized buffer and trigger a WARN_ON() in tmc_etr_enable_hw(). The practical technical effect is local kernel instability and potential denial of service on systems exposing and using the affected CoreSight TMC-ETR functionality, especially ARM64 platforms with CoreSight tracing enabled. The CVSS vector indicates local access, low privileges, high attack complexity, no user interaction, and high availability impact, with no direct confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can disrupt affected Linux systems by causing kernel warnings and potentially destabilizing tracing or the host, leading to outages or degraded availability on systems that rely on ARM CoreSight tracing capabilities. The business risk is generally limited because exploitation requires local low-privileged access, specific hardware/kernel configuration, and a timing-sensitive race; EPSS is very low and there is no known CISA KEV listing or reported ransomware use. However, for embedded, telecom, mobile, lab, observability, or production ARM platforms where CoreSight is enabled, the operational impact can be meaningful if local users or compromised workloads can repeatedly trigger kernel instability.

How an attack unfolds

An attacker first obtains local access to an affected Linux system with sufficient permission to interact with CoreSight tracing interfaces exposed through sysfs and perf. The attacker then attempts to start sysfs-mode tracing while simultaneously initiating perf-mode tracing against the same TMC-ETR sink. By carefully timing these operations, sysfs mode allocates its buffer and releases the driver spinlock, after which perf mode acquires the lock and enables hardware using its own ETR buffer. When sysfs mode resumes and attempts to enable the hardware, it observes that drvdata->etr_buf has already been initialized by perf mode and triggers the kernel WARN_ON() in tmc_etr_enable_hw(). Repeated triggering may cause service instability, tracing subsystem disruption, excessive kernel logging, or denial-of-service conditions depending on kernel panic-on-warn settings and platform behavior.

How to fix it

Apply a Linux kernel update containing the upstream fix for the CoreSight TMC-ETR race condition. The fix adds a second check before sysfs-mode hardware enablement to verify whether perf mode has started using the ETR, preventing sysfs mode from enabling hardware with a conflicting buffer state. If vendor-specific fixed package versions are not yet available, track the relevant distribution, device vendor, or kernel stable branch advisories for backported fixes. As interim mitigations, restrict local access to CoreSight sysfs/debugfs interfaces and perf where operationally feasible; limit access to tracing groups; consider setting stricter kernel.perf_event_paranoid values; avoid exposing debugfs/sysfs tracing controls to untrusted users or containers; disable or unload unused CoreSight TMC modules where supported; and review panic_on_warn settings to avoid converting this warning into a full system crash unless required by policy.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the vendor patch for the CoreSight TMC-ETR sysfs/perf race. Check distribution kernel changelogs or source packages for the relevant coresight-tmc-etr fix. On source-based or custom kernels, inspect drivers/hwtracing/coresight/coresight-tmc-etr.c for logic that rechecks whether CS_MODE_PERF or perf ownership is active before sysfs-mode hardware enablement after sysfs buffer allocation. Validate operationally on non-production ARM/CoreSight-capable hardware by attempting concurrent sysfs and perf tracing operations and confirming that the kernel no longer emits WARN_ON traces from tmc_etr_enable_hw(). Also confirm that access controls around perf, sysfs, and debugfs tracing interfaces match the intended exposure model.

Typical attack path

1. Gain local shell or code execution as an unprivileged or low-privileged user on an affected Linux system.
2. Confirm that ARM CoreSight TMC-ETR tracing devices are present and exposed through sysfs/debugfs/perf interfaces.
3. Launch or script concurrent sysfs-mode CoreSight tracing enablement and perf-mode tracing operations targeting the same ETR sink.
4. Race the sysfs buffer allocation path against the perf hardware enablement path.
5. Trigger the WARN_ON() in tmc_etr_enable_hw() when sysfs mode attempts to enable hardware after perf mode has already initialized the ETR buffer.
6. Repeat the race to degrade availability, flood kernel logs, disrupt tracing, or potentially crash systems configured to panic on kernel warnings.

How to detect it

Look for evidence of attempted or successful triggering in kernel logs, system journals, audit logs, and process execution telemetry. Primary indicators are kernel WARN_ON traces referencing tmc_etr_enable_hw, coresight-tmc-etr.c, coresight_tmc, tmc_enable_etr_sink, coresight_enable_sysfs, or enable_source_store. Review logs for repeated invocations of perf, concurrent writes to CoreSight sysfs enable files, and access to CoreSight tracing paths under /sys/bus/coresight/devices/ or debugfs tracing paths. On systems with auditd or EDR process telemetry, correlate kernel warnings with local users or processes running perf, shell scripts, test harnesses, or container workloads that interact with CoreSight sysfs nodes. Because there are no known public exploit campaigns or KEV activity for this issue, detection should focus on local misuse patterns, repeated warning traces, and suspicious access to hardware tracing interfaces rather than network indicators.

• WARNING: CPU:
• tmc_etr_enable_hw
• drivers/hwtracing/coresight/coresight-tmc-etr.c
• coresight_tmc
• tmc_enable_etr_sink
• coresight_enable_path
• coresight_enable_sysfs
• enable_source_store
• WARN_ON(drvdata->etr_buf)
• /sys/bus/coresight/devices/
• /sys/kernel/debug/coresight/
• perf record
• perf stat
• perf trace
• kernel.perf_event_paranoid

What your security team should do

• Prioritize patching ARM64 or embedded Linux systems where CoreSight TMC-ETR is enabled and local users, containers, CI jobs, or third-party workloads can access tracing interfaces.
• Inventory systems with loaded CoreSight modules, especially coresight_tmc, and determine whether sysfs/debugfs tracing controls or perf events are accessible to non-administrative users.
• Reduce exposure by tightening perf access controls, restricting tracing-related sysfs/debugfs permissions, and preventing untrusted containers from accessing host tracing devices or privileged kernel interfaces.
• Review kernel panic_on_warn settings on affected systems; if enabled, this issue may be more likely to produce a full denial of service rather than only a warning.
• Monitor kernel logs for repeated CoreSight TMC-ETR WARN_ON traces, especially from processes invoking perf or writing to CoreSight sysfs enable controls.
• Track Linux distribution and hardware vendor advisories for exact fixed kernel package versions and apply updates during the next appropriate maintenance window, or sooner for multi-user systems with accessible tracing interfaces.