CWE-1262 covers products that expose hardware through memory-mapped I/O registers without proper access control on them. It applies to SoC designers, driver authors and hypervisor developers. Several real CVEs show it from the software side, where a guest or driver reaches registers it should not.
How it happens
Software usually reaches peripherals in a SoC through a memory-mapped register interface. Anything security-critical that is reachable directly or indirectly through those registers can be tampered with by malicious software, harming confidentiality and integrity.
That makes the register interface an attack surface that can be used to run untrusted code on the system. MITRE's example is a cryptographic accelerator. Software needs registers to select modes and supply plaintext or ciphertext. But if key material stored in registers inside the accelerator can be read by software, the keys leak. MITRE's guidance is that key material in registers should never be readable by software. Even when software can supply a key, all read-back paths should be disabled.
A second example comes from a deliberately buggy RISC-V core in a hardware security contest. Its control and status registers have different privilege levels, and machine mode registers, the highest privilege, should not be accessible from user, supervisor or hypervisor modes.
MITRE's observed examples:
- CVE-2014-2915: a virtualization product does not restrict access to debug and other processor registers, allowing a host or guest OS crash (Gold page).
- CVE-2021-3011: a virtual interrupt controller lets a certain invalid register value crash the host (Gold page).
- CVE-2020-12446: a driver exposes Model Specific Registers, allowing admin privileges (Gold page).
- CVE-2015-2150: a virtualization product does not restrict access to PCI command registers, allowing a guest to crash the host (Gold page).
What an attacker gains
The record lists reading and modifying memory and application data, gaining privileges or assuming identity, bypassing protection mechanisms, altering execution logic and reaching unexpected states. Hardware assets can lose confidentiality if the protected values can be read out by software that should not see them.
How to find it
MITRE lists several methods:
- Manual analysis at architecture. Before implementation starts, make sure the access policy is specified for the whole memory map. This alone does not prove the implementation is right.
- Manual analysis of the implementation. Registers that control hardware should have access control. Check how trusted parties are set, how they are verified and how accesses are verified. Effectiveness varies with the interface complexity.
- Simulation and emulation. Write and run test cases for memory-mapped registers to check the access policy. Covering the whole memory space can be hard.
- Formal verification. Write assertions that capture illegal register access and prove they cannot occur. Formal methods are exhaustive and rated high, though cases for large designs are complex to create.
How to fix it
MITRE's mitigations: at design, set proper policies for software access to hardware registers. At implementation, make sure the access control policies are built as specified.
For software projects that expose hardware to guests or users, the CVEs above point to the same rule. Check who may touch each register, and refuse by default.
Quick check
Should software ever be able to read key material back from key registers?
According to MITRE, no. Even when software supplies the key, all read-back paths to software should be disabled.
Which detection method is rated highest?
Formal verification, which can prove illegal register access scenarios cannot occur, though building the assertions for a large design is hard.
