CWE-1223: Race Condition for Write-Once Attributes

Extended Description

Integrated circuits and hardware IP software programmable controls and settings are commonly stored in register circuits. These register contents have to be initialized at hardware reset to defined default values that are hard coded in the hardware description language (HDL) code of the hardware unit. A common security protection method used to protect register settings from modification by software is to make them write-once. This means the hardware implementation only allows writing to such registers once, and they become read-only after having been written once by software. This is useful to allow initial boot software to configure systems settings to secure values while blocking runtime software from modifying such hardware settings. Implementation issues in hardware design of such controls can expose such registers to a race condition security flaw. For example, consider a hardware design that has two different software/firmware modules executing in parallel. One module is trusted (module A) and another is untrusted (module B). In this design it could be possible for Module B to send write cycles to the write-once register before Module A. Since the field is write-once the programmed value from Module A will be ignored and the pre-empted value programmed by Module B will be used by hardware.

Code Examples & CVEs

Demonstrative Examples

Consider the example design module system Verilog code shown below. register_write_once_example module is an example of register that has a write-once field defined. Bit 0 field captures the write_once_status value.

The first system component that sends a write cycle to this register can program the value. This could result in a race condition security issue in the SoC design, if an untrusted agent is running in the system in parallel with the trusted component that is expected to program the register.

BadVerilog

module register_write_once_example                         ( 						                           input [15:0] Data_in,                           input Clk,                           input ip_resetn,                           input global_resetn,                           input write,                           output reg [15:0] Data_out 						                         );                                                  reg Write_once_status;                                                  always @(posedge Clk or negedge ip_resetn)                         if (~ip_resetn) 						                           begin 						   							Data_out <= 16'h0000;  							Write_once_status <= 1'b0; 						   						  end 						                         else if (write & ~Write_once_status)  						                           begin 						   							Data_out <= Data_in & 16'hFFFE; // Input data written to register after masking bit 0 							Write_once_status <= 1'b1; // Write once status set after first write. 						   						  end 						 						else if (~write) 						                           begin 						   							Data_out[15:1] <= Data_out[15:1]; 							Data_out[0] <= Write_once_status; 						                             end 						 						endmodule

GoodOther

Trusted firmware or software trying to set the write-once field: 						 						  Must confirm the Write_once_status (bit 0) value is zero, before programming register. If another agent has programmed the register before, then Write_once_status value will be one. 						  After writing to the register, the trusted software can issue a read to confirm that the valid setting has been programmed.

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Verify controls for CWE-1223 with SSDF evidence

Use NIST SSDF verification and vulnerability-response practices to detect CWE-1223, Race Condition for Write-Once Attributes, throughout the product lifecycle. Derive review questions, static or dynamic checks, and negative tests from the CWE's causal behavior; define the components and lifecycle stages each check covers; and retain findings with enough evidence to distinguish the root cause from symptoms and impacts. Track escapes and false negatives, then improve the verification plan after every confirmed occurrence.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Address Race Condition for Write-Once Attributes during Architecture and Design

MITRE associates mitigation with Architecture and Design; documented detection approaches include Automated Analysis; recorded impacts include Bypass Protection Mechanism. Use these source-defined anchors to turn CWE-1223 into implementation, review, and verification checks for the affected component.

CWE-1223: Race Condition for Write-Once Attributes — MITRE CWE

Triage CWE-1223 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-1223, Race Condition for Write-Once Attributes, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

Apply precise root-cause mapping to CWE-1223

Apply MITRE's full root-cause mapping guidance when using CWE-1223, Race Condition for Write-Once Attributes. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.

CVE to CWE Root Cause Mapping Guidance — MITRE CWE

Validate CWE-1223 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-1223, Race Condition for Write-Once Attributes. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick Tips — MITRE CWE

Frequently Asked Questions

What is CWE-1223: Race Condition for Write-Once Attributes?+

CWE-1223: Race Condition for Write-Once Attributes is a Common Weakness Enumeration (CWE) entry maintained by MITRE. A write-once register in hardware design is programmable by an untrusted software component earlier than the trusted software component, resulting in a race condition issue. Integrated circuits and hardware IP software programmable controls and settings are commonly stored in register circuits. These register contents have to be initialized at hardware reset to defined default values that are hard coded in the hardware description language (HDL) code of the hardware unit. A common security protection method used to protect register settings from modification by software is to make them write-once. This means the hardware implementation only allows writing to such registers once, and they become read-only after having been written once by software. This is useful to allow initial boot software to configure systems settings to secure values while blocking runtime software from modifying such hardware settings. Implementation issues in hardware design of such controls can expose such registers to a race condition security flaw. For example, consider a hardware design that has two different software/firmware modules executing in parallel. One module is trusted (module A) and another is untrusted (module B). In this design it could be possible for Module B to send write cycles to the write-once register before Module A. Since the field is write-once the programmed value from Module A will be ignored and the pre-empted value programmed by Module B will be used by hardware.

What are the security consequences of Race Condition for Write-Once Attributes?+

If exploited, CWE-1223 (Race Condition for Write-Once Attributes) it can compromise Access Control, leading to outcomes such as Bypass Protection Mechanism.

How do you prevent or mitigate Race Condition for Write-Once Attributes?+

Recommended mitigations for CWE-1223 include: During hardware design, all register write-once or sticky fields must be evaluated for proper configuration.

How is Race Condition for Write-Once Attributes detected?+

CWE-1223 can be detected using Automated Analysis. Combining automated tooling with manual review typically yields the best coverage.

Which programming languages are affected by Race Condition for Write-Once Attributes?+

CWE-1223 commonly affects Verilog and VHDL. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-1223 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

CWE-1223: Race Condition for Write-Once Attributes

Extended Description

Technical Details

Applicable To

Security Consequences

Scope

Impact

Mitigation Strategies

Phase

Description

Detection Methods

Method