CVE-2026-90274 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
coresight: etm4x: fix underflow for usage of (nrseqstate - 1)
According to IHI006H Embedded Trace Macrocell Architecture Specification[0], TRCSEQEVR<n> is implemented only when
TRCIDR5.NUMSEQSTATE is 0b100, in which case n ranges from 0 to 2; otherwise, TRCIDR5.NUMSEQSTATE is 0b000.
IOW, the number of usage in the initialisation or setting TRCSEQEVR<n> with drvdata->nrseqstate - 1 in the loop could make underflow issue when TRCIDR5.NUMSEQSTATE is 0b000.
Therefore, introduce nr_seq_ctrls field and untie it from nrseqstate. As part of this introduce ETM_MAX_SEQ_TRANSITIONS macro and apply nr_seq_ctrls and above macro to TRCSEQEVR<n> relevant fields setup.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel vulnerability identified in the coresight etm4x driver involves a critical integer underflow issue within the initialization logic for trace sequence event registers. This flaw stems from an incorrect assumption regarding the hardware capabilities of Embedded Trace Macrocell (ETM) version 4.x implementations, specifically concerning the number of supported sequence state transitions. The underlying technical error occurs when the code calculates the upper bound for a loop that configures TRCSEQEVR<n> registers by subtracting one from the driver data field nrseqstate. This arithmetic operation assumes that nrseqstate is always greater than zero and accurately reflects the available hardware resources, but fails to account for scenarios where the hardware reports no support for sequence state features.
According to the IHI006H Embedded Trace Macrocell Architecture Specification, the TRCSEQEVR<n> registers are implemented only when the TRCIDR5.NUMSEQSTATE field is set to binary 100, indicating that three such registers (n ranging from 0 to 2) exist. In all other cases where NUMSEQSTATE is zero or otherwise indicates no support for sequence states, these registers do not physically exist in the hardware implementation. However, the vulnerable code path proceeds with a loop using drvdata->nrseqstate - 1 as the limit even when this value results from a context where nrseqstate might be interpreted incorrectly or when the hardware does not support these features at all. If nrseqstate is zero or if the logic erroneously applies to non-existent registers, subtracting one leads to an unsigned integer underflow because the variable type used for counting register indices is typically unsigned. This results in a massive positive value being used as the loop bound, causing the kernel to attempt writing to memory-mapped I/O addresses that are far beyond the valid range of the ETM4x trace registers.
The operational impact of this vulnerability can be severe depending on the execution context and system configuration. An underflow leading to out-of-bounds writes into hardware register space can corrupt unrelated peripheral configurations, trigger undefined behavior in the CPU debug subsystem, or cause a kernel panic if memory protection mechanisms are active. In embedded systems where coresight is used for real-time tracing and debugging, such corruption could lead to silent data loss during trace capture, system instability, or complete failure of the diagnostic infrastructure. This represents a significant reliability risk for developers relying on ETM4x hardware for performance analysis and fault isolation in production environments.
From a security perspective, this flaw aligns with CWE-190 (Integer Overflow or Wraparound) and specifically manifests as an underflow due to unsigned arithmetic without proper bounds checking before the subtraction operation. It also relates to CWE-787 (Out-of-bounds Write) because the loop iterates over invalid register indices, potentially writing data to unauthorized memory-mapped locations. In terms of MITRE ATT&CK mapping, this vulnerability could be leveraged in a local privilege escalation scenario if an attacker can trigger the initialization path with specific hardware configurations or manipulate driver state prior to execution, although it is primarily classified as a stability and integrity issue rather than a direct remote exploitation vector. The lack of validation against the actual hardware capability reported by TRCIDR5 allows the software to proceed with operations that are invalid for the current silicon revision.
To mitigate this vulnerability, the fix introduces a dedicated field named nr_seq_ctrls which is decoupled from the general nrseqstate variable. This new field explicitly tracks the number of sequence control registers available based on accurate hardware detection rather than relying on potentially misleading or incorrectly interpreted state variables. The solution also incorporates the ETM_MAX_SEQ_TRANSITIONS macro to enforce strict upper bounds during the setup of TRCSEQEVR<n> relevant fields. By tying the loop limits directly to validated hardware capabilities and using a dedicated counter that respects architectural constraints, the driver ensures that it never attempts to access non-existent registers or perform arithmetic operations that could result in underflow. This approach enforces defensive programming practices by validating resource availability before allocation or iteration, thereby preventing out-of-bounds accesses and ensuring robust operation across diverse ETM4x hardware implementations.