CWE

Common Weakness Enumeration

Celebrating 20 years of community-developed cybersecurity weakness knowledge!
New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE-1476: Improper Request Propagation before Data Reception in Write Transactions in a Bus Architecture (5.0)  
ID

CWE-1476: Improper Request Propagation before Data Reception in Write Transactions in a Bus Architecture

Weakness ID: 1476
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
Shows the description and diagram, platforms, mitigations, consequences, relationships, memberships, and content history. For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product uses a multi-manager shared bus architecture with an on-chip interconnect that speculatively propagates a request for a write transaction, but it does not ensure that the remaining steps required by the manager module to complete the request are fulfilled in a timely manner.
+ Technical Nuance
Here, the word "speculatively" refers to the fact that the interconnect propagates the request assuming that the manager will at some point provide the data, thus releasing the use of the bus.
+ 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.
Impact Details

DoS: Prevent Access

Scope: Availability

Likelihood: High

The technical impact could include Memory-access delays, I/O access delays, deadline miss, etc.

The attacker can leverage this weakness to generate unbounded delays and denial of service (DoS) in the access of shared resources. The system interconnect might be left in an inconsistent state, requiring a partial or full reset of the network, according to the implementation. The scenario may play out as follows. The interconnect receives a write request from a controller initiator (e.g., sending the header to the interconnect for writing N words of data, with N ranging from 1 to the maximum burst length allowed). The interconnect then speculatively propagates the request to the target peripheral through the shared bus before the corresponding data are received at the interconnect. Here, the word "speculatively" refers to the fact that the interconnect propagates the request, assuming that the controller will at some point provide the data, thus releasing the use of the bus. This speculatively reserves the bus to the manager transaction issuer, which is left free to delay its data provisioning phase. This reserves the whole bus path between the initiator and the target peripheral until all of the words associated with the request are provided by the controller. If the interconnect assumes a cooperative behavior from the controller, it is implicitly trusting that the controller will complete the transaction and release the bus for use from the other controllers. A malicious, faulty, or misbehaving manager module can generate a denial-of-service condition in preventing access to the write data link from all of the other managers in the system, and unboundedly inhibit the write access to one or multiple peripherals in the system (i.e., memories, I/Os, etc.).
+ Potential Mitigations
Phase(s) Mitigation

Hardware Architecture (Hardware); Hardware Microarchitecture (Hardware)

SoC architects can use a switching methodology stopping stalls from being propagated to the interconnect, such as Cut-and-Forward [REF-1585][REF-1587] or Store-and-Forward. Alternatively, a monitoring and recovery module can be added between the interconnect and each manager module to detect stalls introduced by the module and restore a safe state in the interconnect after a stall has been detected [REF-1586].

Effectiveness: High

Note:

The architect should evaluate which methodology better suits the target platform, trading off performance and resource consumption impact [REF-1585][REF-1586][REF-1587].
+ Relationships
Section Help This 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, Overlaps, and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Complete Weakness Hierarchy" (View-1000)
Nature Type ID Name
ChildOf 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. 841 Improper Enforcement of Behavioral Workflow
Overlaps Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1264 Hardware Logic with Insecure De-Synchronization between Control and Data Channels
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Grouping Grouping - a CWE entry that contains a set of other entries that share a common characteristic. 1203 Peripherals, On-chip Fabric, and Interface/IO Problems
+ Background Details

Some products may use an architecture with a shared bus that is accessible by multiple devices, in which these devices can issue requests that utilize the shared bus. There may be an on-chip interconnect based on a protocol that manages the devices' requests to the bus and enforces the ordering of requests and data. When a device makes a request, the bus might indefinitely lock the write access to a shared output link until the initiating device finishes its transaction. If the initiating device does not finish the transaction quickly enough, this can prevent other devices from using the bus, causing a denial of service.

A "manager module" is a hardware component that initiates transactions on the interconnect, such as a processor, DMA engine, or hardware accelerator.

+ 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.
Phase(s) Note

Hardware Requirements (Hardware)

This occurs if the on-chip communication interconnect is based on a multi-channel on-chip communication standard assuming cooperative behavior among the manager modules AND an unsafe switching methodology (e.g., cut-through) is in use. Some switching methodologies may be susceptible to this weakness in modern on-chip multi-channel communication standards, such as the cut-through switching policy, a switching methodology for high performance commonly implemented at the interconnect level. In cut-through, a request is propagated independently on the receipt at the interconnect level of the corresponding data. If the manager module issuing a write request delays the provisioning of the corresponding data, the other manager modules experience delays in accessing the bus. Such delays are capable of generating denial of service.
+ 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.
Type Applicable Platforms Notes
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Architectures

ARM (Undetermined Prevalence)

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Bus/Interface Hardware (Undetermined Prevalence)

Communication Hardware (Undetermined Prevalence)

Class: System on Chip (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


In a system-on-chip, multiple hardware components may communicate with shared resources through an interconnect. A manager initiates transactions, while a target is a shared resource such as memory or a peripheral. A shared write path is the portion of the interconnect used by multiple managers to send write data to the same target.

To reduce buffering requirements and propagation latency, an interconnect may use cut-through switching. In protocols where the write request and corresponding write data are transferred independently, the interconnect can forward the request before all of the associated write data have arrived.

cut-through diagram

  • (a) Manager A issues a multi-word write request.
  • (b) The interconnect forwards the request to the shared target before receiving all corresponding write data. The shared write path is reserved for Manager A until its data transfer completes.
  • (c) Manager A delays or stops sending the remaining data. The transaction remains incomplete, and the shared write path remains reserved.
  • (d) Manager B attempts to use the same shared path but cannot proceed until Manager A completes the data transfer or a recovery mechanism safely releases the path.

In these diagrams, "reserved" refers to the shared write path serving the target, rather than every operation or route to that target.

The interconnect reserves the shared write path before the data required to complete the transaction are available. In the problematic design shown here, other managers cannot use that shared write path until the corresponding data transfer completes. Thus, the interconnect depends on Manager A to continue making forward progress. If Manager A stalls, the stall propagates into the shared portion of the interconnect and prevents competing transactions from using that shared write path.

(attack code)
 

A faulty or malicious manager can delay or stop providing the remaining write data. If the interconnect does not enforce bounded progress or provide a recovery mechanism, the manager can hold the shared write path indefinitely and cause a denial of service for competing write transactions that require the same shared write path.

(good code)
Example Language: Other 

The interconnect should avoid reserving the shared write path until the data needed to complete the forwarded transaction are available.

One approach is store-and-forward switching the interconnect buffers the request and all corresponding write data before forwarding the request, preventing a manager's input-side stall from propagating into the shared write path. If Manager A delays or stops sending data, its incomplete transaction remains in the input buffer, and the shared write path remains available to transactions from other managers.

store-and-forward diagram

  • (a) Manager A issues a multi-word write request.
  • (b) The interconnect buffers the request and waits for all corresponding write data. The request has not been forwarded, and the shared write path is not yet reserved for Manager A.
  • (c) After all data have been received and buffered, the interconnect forwards the request to the shared target.
  • (d) The interconnect forwards the buffered data without waiting for additional data from Manager A. Completion of the data transfer releases the shared write path. The target completes the write and returns a response through the interconnect to Manager A.

Store-and-forward requires storage for an entire transaction, increasing buffer capacity and hardware area. It also adds buffering latency because forwarding begins only after all corresponding data have arrived. [REF-1585]

(good code)
Example Language: Other 

Cut-and-forward is a second preventive approach. It divides a transaction into smaller transactions and forwards each only after all data for that chunk have been buffered. Like store-and-forward, it prevents a manager's data-provisioning stall from reserving the shared write path. [REF-1585]

Cut-and-forward applies the same principle at a smaller chunk granularity. In Figure 3, a four-word write is divided into two chunks of two words each. The interconnect creates the shorter transactions and combines their responses, so Manager A continues to issue and receive a response for the original transaction. [REF-1585]

cut-and-forward diagram

  • (a) Manager A issues a four-word write request.
  • (b) The interconnect buffers the request and begins receiving the corresponding write data. The request has not been forwarded, so the shared write path is not yet reserved for this transaction.
  • (c) After the first two words have been buffered, the interconnect creates a two-word write request and forwards it with the complete first chunk to the shared target. While forwarding this chunk, the interconnect can receive and buffer the next two words.
  • (d) After the remaining two words have been buffered, the interconnect creates and forwards a second two-word write transaction with the complete second chunk.
  • (e) The shared target completes the two shorter transactions and returns a separate response for each one.
  • (f) The interconnect waits for both responses, combines them into the single response expected for the original transaction, and returns that response to Manager A.

The shared write path is reserved only when a complete chunk is ready. If Manager A delays data for a later chunk, the incomplete chunk remains in the input buffer; the path is not held while waiting for those data and remains available to other managers. Smaller chunks reduce buffering requirements and forwarding delay but increase target-side transaction and response overhead. Larger chunks reduce that overhead but require more buffering and increase the delay before forwarding begins. [REF-1585]

(good code)
Example Language: Other 

A watchdog with protocol-aware recovery is a third, separate mitigation approach. It limits the duration of a stall by restoring the shared path to a usable state. It does not prevent the stall from entering the shared path: other managers may remain blocked until detection and recovery complete. Detection alone does not release the path. [REF-1586]

The behavior illustrated here has been demonstrated in AXI-based interconnects. The weakness is not inherently specific to AXI and can arise in other interconnect protocols with equivalent request/data separation, ordering, resource-commitment, and progress properties. The diagrams omit signal-level details to focus on the shared write path and transaction sequence. [REF-1585][REF-1586]



+ Selected Observed Examples

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
Certain commercial AXI interconnect IPs could allow a manager to cause bus stalls.
+ Detection Methods
Method Details

Architecture or Design Review

Instances of this issue can be detected by manual review of the switching policy implemented in the interconnect and the deployed on-chip communication standard.

Effectiveness: Opportunistic

Note:

Manual review requires to have a full description of the architecture of the interconnect. This information might not be available when a third-party interconnect is used.

Formal Verification

Instances of this issue can be found in manager modules by using property-based verification specifically targeting the detection of stalls propagated to the shared resources [REF-1588].

Effectiveness: High

Simulation / Emulation

Instances of this issue can be found in simulation by synthetically generating stalls at the input of the interconnect and evaluating if the interconnect propagates the stalls at the output or not.

Effectiveness: Moderate

Note:

Simulations should be capable of triggering the stalls. Not all of the Verification IP for on-chip communications might be capable of triggering this issue.
+ 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.
Nature Type ID Name
MemberOf GroupingGrouping - a CWE entry that contains a set of other entries that share a common characteristic. 1410 Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

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.
+ References
[REF-1585] Francesco Restuccia and Ryan Kastner. "Cut and Forward: Safe and Secure Communication for FPGA System on Chips". 2022.
<https://ieeexplore.ieee.org/document/9852740>. (URL validated: 2026-10-22)
[REF-1586] Francesco Restuccia, Alessandro Biondi, Mauro Marinoni and Giorgio Buttazzo. "Safely Preventing Unbounded Delays During Bus Transactions in FPGA-based SoC". 2020.
<https://ieeexplore.ieee.org/abstract/document/9114758>. (URL validated: 2026-10-22)
[REF-1587] Thomas Benz, Alessandro Ottaviano, Robert Balas, Angelo Garofalo, Francesco Restuccia, Alessandro Biondi and Luca Benini. "[AXI-REALM: A lightweight and modular interconnect extension for traffic regulation and monitoring of heterogeneous real-time SoCs". 2024.
<https://ieeexplore.ieee.org/document/10546511>. (URL validated: 2026-10-22)
Alternative URL: <https://arxiv.org/abs/2501.10161>. (URL validated: 2026-10-22)
[REF-1588] Andres Meza, Francesco Restuccia, Ryan Kastner and Jason Oberg. "Safety verification of third-party hardware modules via information flow tracking". 2022.
<https://kastner.ucsd.edu/wp-content/uploads/2022/08/admin/rage22-safety.pdf>. (URL validated: 2026-10-22)
+ Content History
+ Submissions
Submission Date Submitter Organization
2022-08-25
(CWE 5.0, 2026-10-28) 		Francesco Restuccia University of California San Diego
Page Last Updated: Oct 28, 2026
 

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–2026, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.