CWE-1239 describes a hardware product that does not clear sensitive data from the registers inside a hardware block when the user of that block changes. It hits chip designers, SoC integrators and anyone who ships firmware that talks to cryptographic accelerators, because the leftover data sits where software was never meant to look.
How it happens
Most hardware IP, including cryptographic accelerators, keeps working data in local registers. They buffer input and output, hold intermediate values and act as the interface to software. That means passwords or encryption keys can sit in places the user of the block cannot see.
Now change who is using the block. A different operating mode, a different software component or a different tenant gets access. If nothing clears the registers first, the new user can read what the previous user left behind.
MITRE gives a concrete case taken from a deliberately buggy SoC used in a hardware security contest. A SHA256 wrapper exposes 16 memory-mapped registers that hold the message to hash. Once the values are forwarded to the hash core they are no longer needed, but the code has no mechanism to clear them, so they can still be read over the AXI Lite interface.
The process of clearing registers is called zeroization, a term used in standards for cryptographic hardware modules such as FIPS 140.
What an attacker gains
MITRE lists confidentiality as the impact, and says the consequences depend on what data was left behind. If the register held a key, the attacker gets the key. If it held a password, they get the password. The weakness itself gives no code execution, but it hands over whatever the previous user trusted the block with.
How to find it
The MITRE record does not list detection methods for this weakness, so the checks below come from the description itself.
- List every register in the block that can hold sensitive data, including intermediate results.
- For each one, find the event that should clear it: a change of user, a mode switch, a reset, a detected physical attack.
- Check whether that event actually triggers a clear, and whether software can read the register before it happens.
- Check who is responsible for zeroization, the hardware logic or the software that uses the IP. If nobody owns it, it usually does not happen.
How to fix it
MITRE's mitigation is a design rule. Every register that might contain sensitive information needs a policy that says how and when it is cleared. The policy should also say whether the hardware logic or the IP user starts the zeroization at the right moment.
One caution from the same entry. Data can still leak after it has been overwritten from the digital point of view. Physical properties of memory can reveal the history of what was written. MITRE cites the case where the same value written repeatedly leaves memory cells altered enough that the original data can be recovered by physical characterization. Clearing registers is necessary, but it is not a guarantee against a well equipped physical attacker.
Quick check
When should a hardware block clear its registers?
When the user of the block changes, and when a physical attack is detected. Both are named in the MITRE description.
Is writing zeros always enough?
No. MITRE notes that physical characteristics of memory can reveal previously written data even after it has been zeroized digitally.
