The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.

Software commonly accesses peripherals in a System-on-Chip (SoC) or other device through a memory-mapped register interface. Malicious software could tamper with any security-critical hardware data that is accessible directly or indirectly through the register interface, which could lead to a loss of confidentiality and integrity.

Primary

Architecture and Design
This weakness may be exploited if the register interface design does not adequately protect hardware assets from software.

Implementation
Mis-implementation of access control policies may inadvertently allow access to hardware assets through the register interface.

Confidentiality
Integrity
Read Memory
Read Application Data
Modify Memory
Modify Application Data
Gain Privileges or Assume Identity
Bypass Protection Mechanism
Unexpected State
Alter Execution Logic
Confidentiality of hardware assets may be violated if the protected information can be read out by software through the register interface. Registers storing security state, settings, other security-critical data may be corruptible by software without correctly implemented protections.

Manual Analysis
This is applicable in the Architecture phase before implementation started. Make sure access policy is specified for the entire memory map. Manual analysis may not ensure the implementation is correct.
Moderate

Manual Analysis
Registers controlling hardware should have access control implemented. This access control may be checked manually for correct implementation. Items to check consist of how are trusted parties set, how are trusted parties verified, how are accesses verified, etc. Effectiveness of a manual analysis will vary depending upon how complicated the interface is constructed.
Moderate

Simulation / Emulation
Functional simulation is applicable during the Implementation Phase. Testcases must be created and executed for memory mapped registers to verify adherence to the access control policy. This method can be effective, since functional verification needs to be performed on the design, and verification for this weakness will be included. There can be difficulty covering the entire memory space during the test.
Moderate

Formal Verification
Formal verification is applicable during the Implementation phase. Assertions need to be created in order to capture illegal register access scenarios and prove that they cannot occur. Formal methods are exhaustive and can be very effective, but creating the cases for large designs may be complex and difficult.
High

Automated Analysis
Information flow tracking can be applicable during the Implementation phase. Security sensitive data (assets) - for example, as stored in registers - is automatically tracked over time through the design to verify the data doesn't reach illegal destinations that violate the access policies for the memory map. This method can be very effective when used together with simulation and emulation, since detecting violations doesn't rely on specific scenarios or data values. This method does rely on simulation and emulation, so testcases must exist in order to use this method.
High

Architecture or Design Review
Manual documentation review of the system memory map, register specification, and permissions associated with accessing security-relevant functionality exposed via memory-mapped registers.
Moderate

Fuzzing
Perform penetration testing (either manual or semi-automated with fuzzing) to verify that access control mechanisms such as the memory protection units or on-chip bus firewall settings adequately protect critical hardware registers from software access.
Moderate

Architecture and Design
Design proper policies for hardware register access from software.

Implementation
Ensure that access control policies for register access are implemented in accordance with the specified design.

The register interface provides software access to hardware functionality. This functionality is an attack surface. This attack surface may be used to run untrusted code on the system through the register interface. As an example, cryptographic accelerators require a mechanism for software to select modes of operation and to provide plaintext or ciphertext data to be encrypted or decrypted as well as other functions. This functionality is commonly provided through registers.
Cryptographic key material stored in registers inside the cryptographic accelerator can be accessed by software.
Key material stored in registers should never be accessible to software. Even if software can provide a key, all read-back paths to software should be disabled.

The example code is taken from the Control/Status Register (CSR) module inside the processor core of the HACK@DAC'19 buggy CVA6 SoC [REF-1340]. In RISC-V ISA [REF-1341], the CSR file contains different sets of registers with different privilege levels, e.g., user mode (U), supervisor mode (S), hypervisor mode (H), machine mode (M), and debug mode (D), with different read-write policies, read-only (RO) and read-write (RW). For example, machine mode, which is the highest privilege mode in a RISC-V system, registers should not be accessible in user, supervisor, or hypervisor modes.

if (csr_we || csr_read) begin

if ((riscv::priv_lvl_t'(priv_lvl_o & csr_addr.csr_decode.priv_lvl) != csr_addr.csr_decode.priv_lvl) && !(csr_addr.address==riscv::CSR_MEPC)) begin

csr_exception_o.cause = riscv::ILLEGAL_INSTR;
csr_exception_o.valid = 1'b1;

end
// check access to debug mode only CSRs
if (csr_addr_i[11:4] == 8'h7b && !debug_mode_q) begin

csr_exception_o.cause = riscv::ILLEGAL_INSTR;
csr_exception_o.valid = 1'b1;

end

end

The vulnerable example code allows the machine exception program counter (MEPC) register to be accessed from a user mode program by excluding the MEPC from the access control check. MEPC as per the RISC-V specification can be only written or read by machine mode code. Thus, the attacker in the user mode can run code in machine mode privilege (privilege escalation).
To mitigate the issue, fix the privilege check so that it throws an Illegal Instruction Exception for user mode accesses to the MEPC register. [REF-1345]

if (csr_we || csr_read) begin

if ((riscv::priv_lvl_t'(priv_lvl_o & csr_addr.csr_decode.priv_lvl) != csr_addr.csr_decode.priv_lvl)) begin

csr_exception_o.cause = riscv::ILLEGAL_INSTR;
csr_exception_o.valid = 1'b1;

end
// check access to debug mode only CSRs
if (csr_addr_i[11:4] == 8'h7b && !debug_mode_q) begin

csr_exception_o.cause = riscv::ILLEGAL_INSTR;
csr_exception_o.valid = 1'b1;

end

end

CVE-2014-2915
virtualization product does not restrict access to debug and other processor registers in the hardware, allowing a crash of the host or guest OS
https://www.cve.org/CVERecord?id=CVE-2014-2915

CVE-2021-3011
virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code
https://www.cve.org/CVERecord?id=CVE-2021-3011

CVE-2020-12446
Driver exposes access to Model Specific Register (MSR) registers, allowing admin privileges.
https://www.cve.org/CVERecord?id=CVE-2020-12446

CVE-2015-2150
Virtualization product does not restrict access to PCI command registers, allowing host crash from the guest.
https://www.cve.org/CVERecord?id=CVE-2015-2150

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Nicole Fern
Cycuity (originally submitted as Tortuga Logic)
2020-05-08
4.1
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns

CWE Content Team
MITRE
2021-10-28
updated Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, Weakness_Ordinalities

CWE Content Team
MITRE
2022-04-28
updated Related_Attack_Patterns

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Demonstrative_Examples, Mapping_Notes, References

CWE Content Team
MITRE
2023-10-26
updated Demonstrative_Examples

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated Relationships

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Demonstrative_Examples, References

Anders Nordstrom, Alric Althoff
Cycuity (originally submitted as Tortuga Logic)
2021-10-11
Provided detection methods and observed examples

Nicole Fern
Riscure
2021-10-12
Provided detection methods

Shaza Zeitouni, Mohamadreza Rostami, Pouya Mahmoody, Ahmad-Reza Sadeghi
Technical University of Darmstadt
2023-06-21
suggested demonstrative example

Rahul Kande, Chen Chen, Jeyavijayan Rajendran
Texas A&M University
2023-06-21
suggested demonstrative example

Register Interface Allows Software Access to Sensitive Data or Security Settings