CWE-1298: Hardware Logic Contains Race Conditions
A race condition in the hardware logic results in undermining security guarantees of the system.
Last updated
Overview
A race condition in logic circuits typically occurs when a logic gate gets inputs from signals that have traversed different paths while originating from the same source. Such inputs to the gate can change at slightly different times in response to a change in the source signal. This results in a timing error or a glitch (temporary or permanent) that causes the output to change to an unwanted state before settling back to the desired state. If such timing errors occur in access control logic or finite state machines that are implemented in security sensitive flows, an attacker might exploit them to circumvent existing protections.
Real-world CVEs
2 recorded CVEs are caused by CWE-1298 (Hardware Logic Contains Race Conditions). The highest-severity and most recent are shown first.
Common consequences
What can happen when CWE-1298 is exploited.
Bypass Protection Mechanism, Gain Privileges or Assume Identity, Alter Execution Logic
Affects: Access Control
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
Technologies
How to prevent it
Practical mitigations for CWE-1298, grouped by where in the lifecycle they apply.
Adopting design practices that encourage designers to recognize and eliminate race conditions, such as Karnaugh maps, could result in the decrease in occurrences of race conditions.
Logic redundancy can be implemented along security critical paths to prevent race conditions. To avoid metastability, it is a good practice in general to default to a secure state in which access is not given to untrusted agents.
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The code below shows a 2x1 multiplexor using logic gates. Though the code shown below results in the minimum gate solution, it is disjoint and causes glitches.
Vulnerable example
input wire in0, in1, sel,The example code is taken from the DMA (Direct Memory Access) module of the buggy OpenPiton SoC of HACK@DAC'21. The DMA contains a finite-state machine (FSM) for accessing the permissions using the physical memory protection (PMP) unit.
PMP provides secure regions of physical memory against unauthorized access. It allows an operating system or a hypervisor to define a series of physical memory regions and then set permissions for those regions, such as read, write, and execute permissions. When a user tries to access a protected memory area (e.g., through DMA), PMP checks the access of a PMP address (e.g., pmpaddr_i) against its configuration (pmpcfg_i). If the access violates the defined permissions (e.g., CTRL_ABORT), the PMP can trigger a fault or an interrupt. This access check is implemented in the pmp parametrized module in the below code snippet. The below code assumes that the state of the pmpaddr_i and pmpcfg_i signals will not change during the different DMA states (i.e., CTRL_IDLE to CTRL_DONE) while processing a DMA request (via dma_ctrl_reg). The DMA state machine is implemented using a case statement (not shown in the code snippet).
Vulnerable example
input [7:0] [16-1:0] pmpcfg_i;Safe example
input [7:0] [16-1:0] pmpcfg_i;However, the above code [REF-1394] allows the values of pmpaddr_i and pmpcfg_i to be changed through DMA's input ports. This causes a race condition and will enable attackers to access sensitive addresses that the configuration is not associated with.
Attackers can initialize the DMA access process (CTRL_IDLE) using pmpcfg_i for a non-privileged PMP address (pmpaddr_i). Then during the loading state (CTRL_LOAD), attackers can replace the non-privileged address in pmpaddr_i with a privileged address without the requisite authorized access configuration.
To fix this issue (see [REF-1395]), the value of the pmpaddr_i and pmpcfg_i signals should be stored in local registers (pmpaddr_reg and pmpcfg_reg at the start of the DMA access process and the pmp module should reference those registers instead of the signals directly. The values of the registers can only be updated at the start (CTRL_IDLE) or the end (CTRL_DONE) of the DMA access process, which prevents attackers from changing the PMP address in the middle of the DMA access process.
Attack patterns
CAPEC attack patterns that exploit this weakness.
Frequently asked questions
Common questions about CWE-1298.
- What is CWE-1298?
- A race condition in the hardware logic results in undermining security guarantees of the system.
- What CVEs are caused by CWE-1298?
- 2 recorded CVEs are attributed to CWE-1298, including CVE-2023-20827, CVE-2023-45733.
- How do you prevent CWE-1298?
- Adopting design practices that encourage designers to recognize and eliminate race conditions, such as Karnaugh maps, could result in the decrease in occurrences of race conditions.
- What are the consequences of CWE-1298?
- Exploiting CWE-1298 can lead to: Bypass Protection Mechanism, Gain Privileges or Assume Identity, Alter Execution Logic.
- Is CWE-1298 actively exploited?
- 2 recorded CVEs are caused by CWE-1298; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-1298) (opens in a new tab)
- CWE-1298 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-1298
Get alerted the moment a new CWE-1298 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.