CWE - CWE-1262: Improper Access Control for Register Interface (4.20)
Home > CWE List > CWE-1262: Improper Access Control for Register Interface (4.20)  
ID
  • Home
  • Who We Are User Stories History Documents Videos
  • Basics
    Root Cause Mapping   ►
    Guidance Quick Tips Examples
    How to Contribute Weakness Content FAQs Glossary
  • Top-N Lists   ►
    Top 25 Software Top Hardware Top 10 KEV Weaknesses
    CWE List   ►
    Current Version Reports Visualizations Releases Archive
    Downloads REST API
  • News   ►
    Current News Blog Podcast News Archive
    CWE Board Working Groups & Special Interest Groups Email Lists
  • Search CWE List Search Website

    CWE-1262: Improper Access Control for Register Interface

    Weakness ID: 1262
    Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
    Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
    View customized information:
    For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
    ×

    Edit Custom Filter


    + Description
    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.
    + Extended Description

    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.

    + Common Consequences
    Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
    Impact Details

    Read Memory; Read Application Data; Modify Memory; Modify Application Data; Gain Privileges or Assume Identity; Bypass Protection Mechanism; Unexpected State; Alter Execution Logic

    		Scope: Confidentiality, Integrity

    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.
    + Potential Mitigations
    Phase(s) Mitigation

    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.
    + Relationships
    Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
    + Relevant to the view "Research Concepts" (View-1000)
    Nature Type ID Name
    ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
    + Relevant to the view "Hardware Design" (View-1194)
    Nature Type ID Name
    MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1198 Privilege Separation and Access Control Issues
    + Modes Of Introduction
    Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
    Phase Note
    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.
    + Applicable Platforms
    Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
    Languages

    Class: Not Language-Specific (Undetermined Prevalence)

    Operating Systems

    Class: Not OS-Specific (Undetermined Prevalence)

    Architectures

    Class: Not Architecture-Specific (Undetermined Prevalence)

    Technologies

    Class: Not Technology-Specific (Undetermined Prevalence)

    + Demonstrative Examples

    Example 1


    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.

    (bad code)
    Example Language: Other 
    Cryptographic key material stored in registers inside the cryptographic accelerator can be accessed by software.
    (good code)
    Example Language: Other 
    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.


    Example 2


    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.

    (bad code)
    Example Language: Verilog 
    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]

    (good code)
    Example Language: Verilog 
    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


    + Selected Observed Examples

    Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

    Reference Description
    virtualization product does not restrict access to debug and other processor registers in the hardware, allowing a crash of the host or guest OS
    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
    Driver exposes access to Model Specific Register (MSR) registers, allowing admin privileges.
    Virtualization product does not restrict access to PCI command registers, allowing host crash from the guest.
    + Weakness Ordinalities
    Ordinality Description
    Primary
    (where the weakness exists independent of other weaknesses)
    + Detection Methods
    Method Details

    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.

    Effectiveness: 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.

    Effectiveness: 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.

    Effectiveness: 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.

    Effectiveness: 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.

    Effectiveness: 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.

    Effectiveness: 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.

    Effectiveness: Moderate
    + Memberships
    Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
    Nature Type ID Name
    MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
    MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1432 Weaknesses in the 2025 CWE Most Important Hardware Weaknesses List
    + Vulnerability Mapping Notes
    Usage ALLOWED
    (this CWE ID may be used to map to real-world vulnerabilities)
    Reason Acceptable-Use

    Rationale

    		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.

    Comments

    		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.
    + References
    [REF-1340] "Hackatdac19 csr_regfile.sv". 2019.
    <https://github.com/HACK-EVENT/hackatdac19/blob/619e9fb0ef32ee1e01ad76b8732a156572c65700/src/csr_regfile.sv#L854:L857>. (URL validated: 2023-06-21)
    [REF-1341] Andrew Waterman, Yunsup Lee, Rimas Avižienis, David Patterson and Krste Asanović. "The RISC-V Instruction Set Manual". Volume II: Privileged Architecture. 2016-11-04.
    <https://people.eecs.berkeley.edu/~krste/papers/riscv-privileged-v1.9.1.pdf>. (URL validated: 2023-06-21)
    [REF-1345] Florian Zaruba, Michael Schaffner and Andreas Traber. "csr_regfile.sv". 2019.
    <https://github.com/openhwgroup/cva6/blob/7951802a0147aedb21e8f2f6dc1e1e9c4ee857a2/src/csr_regfile.sv#L868:L871>. (URL validated: 2023-06-21)
    + Content History
    + Submissions
    Submission Date Submitter Organization
    2020-05-08
    (CWE 4.1, 2020-02-24)     		Nicole Fern Cycuity (originally submitted as Tortuga Logic)
    + Contributions
    Contribution Date Contributor Organization
    2023-06-21 Shaza Zeitouni, Mohamadreza Rostami, Pouya Mahmoody, Ahmad-Reza Sadeghi Technical University of Darmstadt
    suggested demonstrative example
    2023-06-21 Rahul Kande, Chen Chen, Jeyavijayan Rajendran Texas A&M University
    suggested demonstrative example
    2021-10-12 Nicole Fern Riscure
    Provided detection methods
    2021-10-11 Anders Nordstrom, Alric Althoff Cycuity (originally submitted as Tortuga Logic)
    Provided detection methods and observed examples
    + Modifications
    Modification Date Modifier Organization
    2025-12-11
    (CWE 4.19, 2025-12-11)     		CWE Content Team MITRE
    updated Demonstrative_Examples, References
    2025-09-09
    (CWE 4.18, 2025-09-09)     		CWE Content Team MITRE
    updated Relationships
    2023-10-26
    (CWE 4.13, 2023-10-26)     		CWE Content Team MITRE
    updated Demonstrative_Examples
    2023-06-29
    (CWE 4.12, 2023-06-29)     		CWE Content Team MITRE
    updated Demonstrative_Examples, Mapping_Notes, References
    2023-04-27
    (CWE 4.11, 2023-04-27)     		CWE Content Team MITRE
    updated Relationships
    2022-04-28
    (CWE 4.7, 2022-04-28)     		CWE Content Team MITRE
    updated Related_Attack_Patterns
    2021-10-28
    (CWE 4.6, 2021-10-28)     		CWE Content Team MITRE
    updated Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, Weakness_Ordinalities
    2020-08-20
    (CWE 4.2, 2020-08-20)     		CWE Content Team MITRE
    updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns
    + Previous Entry Names
    Change Date Previous Entry Name
    2021-10-28 Register Interface Allows Software Access to Sensitive Data or Security Settings
    Page Last Updated: April 30, 2026