CWE-1311 occurs when a bridge incorrectly translates security attributes, from trusted to untrusted or the reverse, while converting from one fabric protocol to another.
How it happens
A bridge lets IP blocks that speak different fabric protocols live in one system. Fabric endpoints have dedicated signals to carry security attributes. MITRE names HPROT in AHB, AxPROT in AXI, and MReqInfo and SRespInfo in OCP. The values describe things like the immutable hardware identity of the controller starting the transaction, its privilege level, and the type of transaction, for example read or write, cacheable or non-cacheable, posted or non-posted.
The bug is in the bridge logic that maps those signals from one protocol to the other. If an untrusted transaction comes out the other side looking trusted, protections downstream are bypassed. If a trusted one comes out looking untrusted, the system can misbehave in the other direction.
What an attacker gains
MITRE lists: read and modify memory, gain privileges or assume identity, bypass protection mechanisms, execute unauthorized code or commands, and confidentiality and integrity loss.
How to find it
The record lists no detection methods. Compare the signal mapping table of each bridge against the source and destination specifications. Then run transactions of each trust level and privilege through the bridge and check what appears on the other side.
How to fix it
MITRE's guidance for both design and implementation is the same: the translation must map signals so that untrusted agents cannot map to trusted agents or the reverse. Make that a testable property of every bridge.
Quick check
Which attributes does a bridge need to carry faithfully?
Hardware identity of the initiator, privilege level and transaction type, among the attributes MITRE describes.
