CWE-1316 describes an on-chip fabric address map in which protected and unprotected regions overlap. An attacker can bypass access control for the overlapping part of the protected region.
How it happens
A system address map defines ranges in memory or in memory-mapped IO (MMIO) space. Ranges are usually defined through range registers holding a base address and a size. Address decoding decides which range an incoming transaction is meant for. To keep secrets isolated, ranges that hold secret data are access-control protected.
Overlaps sometimes occur. MITRE says they can be intentional, for example because of a limited number of range registers or limited choice in range size, or unintentional, introduced by errors. Some designs also allow dynamic remapping of address ranges assigned to peripheral MMIO ranges. In those designs, malicious software can create overlaps through misconfiguration.
When a protected range and an unprotected range overlap, a transaction aimed at the unprotected range may reach protected content. That violates least privilege.
What an attacker gains
MITRE rates the likelihood as medium. Consequences listed: bypass of protection mechanisms, reading memory and modifying memory, with confidentiality, integrity, access control and authorization affected.
The observed example in the record is CVE-2009-4419. An attacker can modify the MCHBAR register so it overlaps with an attacker-controlled region. That modification prevents the SENTER instruction from properly applying VT-d protection while a Measured Launch Environment is being launched.
How to find it
MITRE lists two detection methods, both rated high effectiveness.
- Automated dynamic analysis: review the address map in the specification to see whether any ranges overlap.
- Manual static analysis: negative testing of access control on overlapped ranges.
Together they cover paper and silicon. First list every range with its base and size and compute overlaps mechanically. Then, for any overlap that exists, try to read and write the protected portion through the unprotected route and confirm it is denied.
How to fix it
MITRE's mitigations by stage:
- Architecture and design: when architecting the chip's address map, keep protected and unprotected ranges isolated so they do not overlap. Ensure ranges hardcoded in Register-Transfer Level (RTL) do not overlap.
- Implementation: ranges configured by firmware should not overlap. If overlaps are mandatory because of constraints such as a limited number of registers, make sure no assets are present in the overlapped portion.
- Testing: validate the mitigation actions with thorough testing.
The third item matters most for firmware-configured designs, since firmware can change the map after the RTL review is done.
Quick check
Is every overlap a vulnerability?
No. MITRE accepts mandatory overlaps if no assets sit in the overlapped portion.
Who can create overlaps at runtime?
In designs with dynamic remapping of MMIO ranges, malicious software can create them by misconfiguration.
