Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

2021 CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.10)  

CWE-1260: Improper Handling of Overlap Between Protected Memory Ranges

Weakness ID: 1260
Abstraction: Base
Structure: Simple
View customized information:
+ Description
The product allows address regions to overlap, which can result in the bypassing of intended memory protection.
+ Extended Description

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.

+ Relationships
Section HelpThis 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" (CWE-1000)
ChildOfPillarPillar - 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.284Improper Access Control
CanPrecedeClassClass - 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.119Improper Restriction of Operations within the Bounds of a Memory Buffer
Section HelpThis 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 "Hardware Design" (CWE-1194)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1198Privilege 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.
Architecture and DesignSuch issues could be introduced during hardware architecture and design or implementation and identified later during the Testing phase.
+ 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.


Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)


Class: Not Architecture-Specific (Undetermined Prevalence)


Memory Hardware (Undetermined Prevalence)

Processor Hardware (Undetermined Prevalence)

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

Technical Impact: Modify Memory; Read Memory; DoS: Instability

+ Demonstrative Examples

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.

  • Address_range[15:0]: specifies the Base address of the region
  • Address_range[31:16]: specifies the size of the region
  • Access_policy[31:0]: specifies what types of software can access a region and which actions are allowed

Certain bits of the access policy are defined symbolically as follows:

  • Access_policy.read_np: if set to one, allows reads from Non_privileged_SW
  • Access_policy.write_np: if set to one, allows writes from Non_privileged_SW
  • Access_policy.execute_np: if set to one, allows code execution by Non_privileged_SW
  • Access_policy.read_p: if set to one, allows reads from Privileged_SW
  • Access_policy.write_p: if set to one, allows writes from Privileged_SW
  • Access_policy.execute_p: if set to one, allows code execution by Privileged_SW

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:

  • Region_0 & Region_1: registers are programmable by Privileged_SW
  • Region_2: registers are programmable by Non_privileged_SW

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.

(bad code)

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.

(good code)
Ensure that software accesses to memory regions are only permitted if all three filters permit access. Additionally, the scheme could define a memory region priority to ensure that Region_2 (the memory region defined by Non_privileged_SW) cannot overlap Region_0 or Region_1 (which are used by Privileged_SW).
+ Observed Examples
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]
+ Potential Mitigations

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

Phase: 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

+ Weakness Ordinalities
(where the weakness exists independent of other weaknesses)
(where the weakness is typically related to the presence of some other weaknesses)
+ Detection Methods

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

+ 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.
MemberOfViewView - 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).1343Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List
+ Notes


As of CWE 4.6, CWE-1260 and CWE-1316 are siblings under view 1000, but CWE-1260 might be a parent of CWE-1316. More analysis is warranted.
+ References
[REF-1100] Christopher Domas. "The Memory Sinkhole". 2015-07-20. <>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-02-10Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V MangipudiIntel Corporation
+ Contributions
Contribution DateContributorOrganization
2021-10-20Narasimha Kumar V MangipudiLattice Semiconductor
suggested content improvements
2021-10-22Hareesh KhattriIntel Corporation
suggested observed examples
+ Modifications
Modification DateModifierOrganization
2020-08-20CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Modes_of_Introduction, Related_Attack_Patterns
2020-12-10CWE Content TeamMITRE
updated Maintenance_Notes
2021-10-28CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Observed_Examples, Relationships, Weakness_Ordinalities
2022-04-28CWE Content TeamMITRE
updated Applicable_Platforms, Related_Attack_Patterns
2022-06-28CWE Content TeamMITRE
updated Applicable_Platforms
2023-01-31CWE Content TeamMITRE
updated Related_Attack_Patterns
More information is available — Please select a different filter.
Page Last Updated: January 31, 2023