Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges

Draft Base
Structure: Simple
Description

This vulnerability occurs when a hardware fabric's address map incorrectly allows protected and unprotected memory regions to overlap. Attackers can exploit this overlap to bypass security controls and access restricted data or functions.

Extended Description

In system-on-chip (SoC) designs, the address map defines protected and unprotected ranges for memory and memory-mapped I/O (MMIO). These ranges, often set by base and size registers, are meant to enforce isolation—keeping sensitive data in access-controlled areas. However, if these ranges are programmed to overlap, either accidentally through a design error or intentionally via malicious software in dynamically reconfigurable systems, the hardware's access control logic can become confused. When a protected range overlaps with an unprotected one, an attacker can craft transactions targeting the overlapping address space. Since the unprotected path provides a valid route, the hardware may fail to apply the proper security checks, allowing unauthorized access. This breach violates the core security principle of least privilege, as the overlap creates a backdoor that circumvents the intended protection mechanisms.

Common Consequences 1
Scope: ConfidentialityIntegrityAccess ControlAuthorization

Impact: Bypass Protection MechanismRead MemoryModify Memory

Detection Methods 2
Automated Dynamic AnalysisHigh
Review address map in specification to see if there are any overlapping ranges.
Manual Static AnalysisHigh
Negative testing of access control on overlapped ranges.
Potential Mitigations 3
Phase: Architecture and Design
When architecting the address map of the chip, ensure that protected and unprotected ranges are isolated and do not overlap. When designing, ensure that ranges hardcoded in Register-Transfer Level (RTL) do not overlap.
Phase: Implementation
Ranges configured by firmware should not overlap. If overlaps are mandatory because of constraints such as a limited number of registers, then ensure that no assets are present in the overlapped portion.
Phase: Testing
Validate mitigation actions with robust testing.
Demonstrative Examples 1
An on-chip fabric supports a 64KB address space that is memory-mapped. The fabric has two range registers that support creation of two protected ranges with specific size constraints--4KB, 8KB, 16KB or 32KB. Assets that belong to user A require 4KB, and those of user B require 20KB. Registers and other assets that are not security-sensitive require 40KB. One range register is configured to program 4KB to protect user A's assets. Since a 20KB range cannot be created with the given size constraints, the range register for user B's assets is configured as 32KB. The rest of the address space is left as open. As a result, some part of untrusted and open-address space overlaps with user B range.
The fabric does not support least privilege, and an attacker can send a transaction to the overlapping region to tamper with user B data.
Since range B only requires 20KB but is allotted 32KB, there is 12KB of reserved space. Overlapping this region of user B data, where there are no assets, with the untrusted space will prevent an attacker from tampering with user B data.
Observed Examples 1
CVE-2009-4419Attacker can modify MCHBAR register to overlap with an attacker-controlled region, which modification prevents the SENTER instruction from properly applying VT-d protection while a Measured Launch Environment is being launched.
References 1
BARing the System - New vulnerabilities in Coreboot & UEFI-based Systems
Yuriy Bulygin, Oleksandr Bazhaniuk, Andrew Furtak, John Loucaides, Mikhail Gorobets
2017
ID: REF-1137
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
Bus/Interface Hardware : UndeterminedNot Technology-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Related Weaknesses