CWE-1223 covers a write-once register in a hardware design that untrusted software can program before the trusted software does. The outcome is a race condition. It matters to SoC and IP designers and to firmware authors who depend on those registers.
How it happens
Software programmable settings live in registers that are initialized to hardcoded defaults at reset. A common protection is to make a setting write-once: the hardware accepts one write, after which the register is read-only. Boot software sets secure values, and runtime software cannot change them.
The race appears when two software or firmware modules run in parallel. MITRE gives an example with a trusted module A and an untrusted module B. If module B sends a write cycle to the write-once register before module A, then the value from module A is ignored, since the field is already locked. The pre-empted value from module B is the one the hardware uses.
The protection worked exactly as designed, and that is the problem. It faithfully preserves whichever value arrived first.
What an attacker gains
The record lists a bypass of a protection mechanism: system configuration cannot be programmed in a secure way.
How to find it
MITRE lists automated analysis. In testing, use automated tools to verify that values are not reprogrammable and that write-once fields lock on writing zeros. Add scenarios where untrusted agents attempt the first write, not only trusted ones.
How to fix it
During hardware design, evaluate every register write-once or sticky field for proper configuration. That includes checking who can reach the register and when, relative to the trusted boot flow. Make sure the trusted code is the only agent able to perform the one write.
Quick check
Why does write-once not help in this race?
It locks after the first write regardless of who made it. If the untrusted module writes first, its value becomes the permanent one.
