Isolated memory regions and access control (read/write) policies are used by hardware to protect privileged software. Software components are often allowed to change or remap memory region definitions in order to enable flexible and dynamically changeable memory management by system software.
If a software component running at lower privilege can program a memory address region to overlap with other memory regions used by software running at higher privilege, privilege escalation may be available to attackers. The memory protection unit (MPU) logic can incorrectly handle such an address overlap and allow the lower-privilege software to read or write into the protected memory region, resulting in privilege escalation attack. An address overlap weakness can also be used to launch a denial of service attack on the higher-privilege software memory regions.
| Impact | Details |
|---|---|
|
Modify Memory; Read Memory; DoS: Instability |
Scope: Confidentiality, Integrity, Availability Likelihood: High |
| Phase(s) | Mitigation |
|---|---|
|
Architecture and Design |
Ensure that memory regions are isolated as intended and that access control (read/write) policies are used by hardware to protect privileged software. |
|
Implementation |
For all of the programmable memory protection regions, the memory protection unit (MPU) design can define a priority scheme. For example: if three memory regions can be programmed (Region_0, Region_1, and Region_2), the design can enforce a priority scheme, such that, if a system address is within multiple regions, then the region with the lowest ID takes priority and the access-control policy of that region will be applied. In some MPU designs, the priority scheme can also be programmed by trusted software. Hardware logic or trusted firmware can also check for region definitions and block programming of memory regions with overlapping addresses. The memory-access-control-check filter can also be designed to apply a policy filter to all of the overlapping ranges, i.e., if an address is within Region_0 and Region_1, then access to this address is only granted if both Region_0 and Region_1 policies allow the access. Effectiveness: High |
| 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 |
| CanPrecede | Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. | 119 | Improper Restriction of Operations within the Bounds of a Memory Buffer |
| 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 |
| Phase | Note |
|---|---|
| Architecture and Design | Such issues could be introduced during hardware architecture and design or implementation and identified later during the Testing phase. |
| Implementation |
Class: Not Language-Specific (Undetermined Prevalence)
Class: Not OS-Specific (Undetermined Prevalence)
Class: Not Architecture-Specific (Undetermined Prevalence)
Memory Hardware (Undetermined Prevalence)
Processor Hardware (Undetermined Prevalence)
Example 1
For example, consider a design with a 16-bit address that has two software privilege levels: Privileged_SW and Non_privileged_SW. To isolate the system memory regions accessible by these two privilege levels, the design supports three memory regions: Region_0, Region_1, and Region_2.
Each region is defined by two 32 bit registers: its range and its access policy.
Certain bits of the access policy are defined symbolically as follows:
For any requests from software, an address-protection filter checks the address range and access policies for each of the three regions, and only allows software access if all three filters allow access.
Consider the following goals for access control as intended by the designer:
The intention is that Non_privileged_SW cannot modify memory region and policies defined by Privileged_SW in Region_0 and Region_1. Thus, it cannot read or write the memory regions that Privileged_SW is using.
Non_privileged_SW can program the Address_range register for Region_2 so that its address overlaps with the ranges defined by Region_0 or Region_1. Using this capability, it is possible for Non_privileged_SW to block any memory region from being accessed by Privileged_SW, i.e., Region_0 and Region_1.
This design could be improved in several ways.
Example 2
The example code below is taken from the IOMMU controller module of the HACK@DAC'19 buggy CVA6 SoC [REF-1338]. The static memory map is composed of a set of Memory-Mapped Input/Output (MMIO) regions covering different IP agents within the SoC. Each region is defined by two 64-bit variables representing the base address and size of the memory region (XXXBase and XXXLength).
In this example, we have 12 IP agents, and only 4 of them are called out for illustration purposes in the code snippets. Access to the AES IP MMIO region is considered privileged as it provides access to AES secret key, internal states, or decrypted data.
The vulnerable code allows the overlap between the protected MMIO region of the AES peripheral and the unprotected UART MMIO region. As a result, unprivileged users can access the protected region of the AES IP. In the given vulnerable example UART MMIO region starts at address 64'h1000_0000 and ends at address 64'h1011_1000 (UARTBase is 64'h1000_0000, and the size of the region is provided by the UARTLength of 64'h0011_1000).
On the other hand, the AES MMIO region starts at address 64'h1010_0000 and ends at address 64'h1010_1000, which implies an overlap between the two peripherals' memory regions. Thus, any user with access to the UART can read or write the AES MMIO region, e.g., the AES secret key.
To mitigate this issue, remove the overlapping address regions by decreasing the size of the UART memory region or adjusting memory bases for all the remaining peripherals. [REF-1339]
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 allows compromise of hardware product by accessing certain remapping registers.
|
|
|
processor design flaw allows ring 0 code to access more privileged rings by causing a register window to overlap a range of protected system RAM [REF-1100]
|
| Ordinality | Description |
|---|---|
|
Primary
|
(where the weakness exists independent of other weaknesses)
|
Resultant
|
(where the weakness is typically related to the presence of some other weaknesses)
|
| Method | Details |
|---|---|
|
Manual Analysis |
Create a high privilege memory block of any arbitrary size. Attempt to create a lower privilege memory block with an overlap of the high privilege memory block. If the creation attempt works, fix the hardware. Repeat the test.
Effectiveness: High |
| Nature | Type | ID | Name |
|---|---|---|---|
| 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). | 1343 | Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List |
| 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 |
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.| Submissions | ||
|---|---|---|
| Submission Date | Submitter | Organization |
|
2020年02月10日
(CWE 4.1, 2020年02月24日) |
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi | Intel Corporation |
| Contributions | ||
| Contribution Date | Contributor | Organization |
| 2021年10月20日 | Narasimha Kumar V Mangipudi | Lattice Semiconductor |
| suggested content improvements | ||
| 2021年10月22日 | Hareesh Khattri | Intel Corporation |
| suggested observed examples | ||
| 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 | ||
| Modifications | ||
| Modification Date | Modifier | Organization |
|
2025年09月09日
(CWE 4.18, 2025年09月09日) |
CWE Content Team | MITRE |
| updated Relationships | ||
| 2023年06月29日 | CWE Content Team | MITRE |
| updated Demonstrative_Examples, Mapping_Notes, References | ||
| 2023年04月27日 | CWE Content Team | MITRE |
| updated Relationships | ||
| 2023年01月31日 | CWE Content Team | MITRE |
| updated Related_Attack_Patterns | ||
| 2022年06月28日 | CWE Content Team | MITRE |
| updated Applicable_Platforms | ||
| 2022年04月28日 | CWE Content Team | MITRE |
| updated Applicable_Platforms, Related_Attack_Patterns | ||
| 2021年10月28日 | CWE Content Team | MITRE |
| updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Observed_Examples, Relationships, Weakness_Ordinalities | ||
| 2020年12月10日 | CWE Content Team | MITRE |
| updated Maintenance_Notes | ||
| 2020年08月20日 | CWE Content Team | MITRE |
| updated Demonstrative_Examples, Description, Modes_of_Introduction, Related_Attack_Patterns | ||
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.