{"@ID": "1476", "@Name": "Improper Request Propagation before Data Reception in Write Transactions in a Bus Architecture", "@Abstraction": "Base", "@Structure": "Simple", "@Status": "Incomplete", "Description": "The product uses a multi-manager shared bus architecture\n\t    with an on-chip interconnect that speculatively propagates\n\t    a request for a write transaction, but it does not ensure\n\t    that the remaining steps required by the manager module to\n\t    complete the request are fulfilled in a timely manner.", "Technical_Nuance": "Here, the word \"speculatively\" refers to the fact that the\n\t    interconnect propagates the request assuming that the\n\t    manager will at some point provide the data, thus\n\t    releasing the use of the bus.", "Related_Weaknesses": {"Related_Weakness": [{"@Nature": "ChildOf", "@CWE_ID": "841", "@View_ID": "1000", "@Ordinal": "Primary"}, {"@Nature": "Overlaps", "@CWE_ID": "1264", "@View_ID": "1000", "@Ordinal": "Primary"}]}, "Applicable_Platforms": {"Language": {"@Class": "Not Language-Specific", "@Prevalence": "Undetermined"}, "Architecture": [{"@Name": "ARM", "@Prevalence": "Undetermined"}, {"@Class": "Not Architecture-Specific", "@Prevalence": "Undetermined"}], "Technology": [{"@Name": "Bus/Interface Hardware", "@Prevalence": "Undetermined"}, {"@Name": "Communication Hardware", "@Prevalence": "Undetermined"}, {"@Class": "System on Chip", "@Prevalence": "Undetermined"}]}, "Background_Details": {"Background_Detail": {"xhtml:p": ["Some products may use an architecture with a\n\t      shared bus that is accessible by multiple devices, in\n\t      which these devices can issue requests that utilize the\n\t      shared bus. There may be an on-chip interconnect based\n\t      on a protocol that manages the devices' requests to the\n\t      bus and enforces the ordering of requests and data. When\n\t      a device makes a request, the bus might indefinitely\n\t      lock the write access to a shared output link until the\n\t      initiating device finishes its transaction. If the\n\t      initiating device does not finish the transaction\n\t      quickly enough, this can prevent other devices from\n\t      using the bus, causing a denial of service.", "A \"manager module\" is a hardware component that\n\t      initiates transactions on the interconnect, such as a\n\t      processor, DMA engine, or hardware\n\t      accelerator."], "#text_blocks": ["Some products may use an architecture with a\n\t      shared bus that is accessible by multiple devices, in\n\t      which these devices can issue requests that utilize the\n\t      shared bus. There may be an on-chip interconnect based\n\t      on a protocol that manages the devices' requests to the\n\t      bus and enforces the ordering of requests and data. When\n\t      a device makes a request, the bus might indefinitely\n\t      lock the write access to a shared output link until the\n\t      initiating device finishes its transaction. If the\n\t      initiating device does not finish the transaction\n\t      quickly enough, this can prevent other devices from\n\t      using the bus, causing a denial of service.", "A \"manager module\" is a hardware component that\n\t      initiates transactions on the interconnect, such as a\n\t      processor, DMA engine, or hardware\n\t      accelerator."]}}, "Modes_Of_Introduction": {"Introduction": {"Custom_Phase": {"@Domain": "Hardware", "#text": "Hardware Requirements"}, "Note": {"xhtml:p": "This occurs if the on-chip communication\n\t\tinterconnect is based on a multi-channel on-chip\n\t\tcommunication standard assuming cooperative behavior\n\t\tamong the manager modules AND an unsafe switching\n\t\tmethodology (e.g., cut-through) is in use.  Some\n\t\tswitching methodologies may be susceptible to this\n\t\tweakness in modern on-chip multi-channel communication\n\t\tstandards, such as the cut-through switching policy, a\n\t\tswitching methodology for high performance commonly\n\t\timplemented at the interconnect level. In cut-through,\n\t\ta request is propagated independently on the receipt\n\t\tat the interconnect level of the corresponding\n\t\tdata. If the manager module issuing a write request\n\t\tdelays the provisioning of the corresponding data, the\n\t\tother manager modules experience delays in accessing\n\t\tthe bus. Such delays are capable of generating denial\n\t\tof service.", "#text_blocks": ["This occurs if the on-chip communication\n\t\tinterconnect is based on a multi-channel on-chip\n\t\tcommunication standard assuming cooperative behavior\n\t\tamong the manager modules AND an unsafe switching\n\t\tmethodology (e.g., cut-through) is in use.  Some\n\t\tswitching methodologies may be susceptible to this\n\t\tweakness in modern on-chip multi-channel communication\n\t\tstandards, such as the cut-through switching policy, a\n\t\tswitching methodology for high performance commonly\n\t\timplemented at the interconnect level. In cut-through,\n\t\ta request is propagated independently on the receipt\n\t\tat the interconnect level of the corresponding\n\t\tdata. If the manager module issuing a write request\n\t\tdelays the provisioning of the corresponding data, the\n\t\tother manager modules experience delays in accessing\n\t\tthe bus. Such delays are capable of generating denial\n\t\tof service."]}}}, "Common_Consequences": {"Consequence": {"Scope": "Availability", "Impact": "DoS: Prevent Access", "Likelihood": "High", "Note": {"xhtml:p": ["The technical impact could include\n\t\tMemory-access delays, I/O access delays, deadline\n\t\tmiss, etc.", "The attacker can leverage this weakness to\n\t\tgenerate unbounded delays and denial of service (DoS)\n\t\tin the access of shared resources. The system\n\t\tinterconnect might be left in an inconsistent state,\n\t\trequiring a partial or full reset of the network,\n\t\taccording to the implementation.  The scenario may\n\t\tplay out as follows. The interconnect receives a write\n\t\trequest from a controller initiator (e.g., sending the\n\t\theader to the interconnect for writing N words of\n\t\tdata, with N ranging from 1 to the maximum burst\n\t\tlength allowed). The interconnect then speculatively\n\t\tpropagates the request to the target peripheral\n\t\tthrough the shared bus before the corresponding data\n\t\tare received at the interconnect. Here, the word\n\t\t\"speculatively\" refers to the fact that the\n\t\tinterconnect propagates the request, assuming that the\n\t\tcontroller will at some point provide the data, thus\n\t\treleasing the use of the bus.  This speculatively\n\t\treserves the bus to the manager transaction issuer,\n\t\twhich is left free to delay its data provisioning\n\t\tphase.  This reserves the whole bus path between the\n\t\tinitiator and the target peripheral until all of the\n\t\twords associated with the request are provided by the\n\t\tcontroller.  If the interconnect assumes a cooperative\n\t\tbehavior from the controller, it is implicitly\n\t\ttrusting that the controller will complete the\n\t\ttransaction and release the bus for use from the other\n\t\tcontrollers. A malicious, faulty, or misbehaving\n\t\tmanager module can generate a denial-of-service\n\t\tcondition in preventing access to the write data link\n\t\tfrom all of the other managers in the system, and\n\t\tunboundedly inhibit the write access to one or\n\t\tmultiple peripherals in the system (i.e., memories,\n\t\tI/Os, etc.)."], "#text_blocks": ["The technical impact could include\n\t\tMemory-access delays, I/O access delays, deadline\n\t\tmiss, etc.", "The attacker can leverage this weakness to\n\t\tgenerate unbounded delays and denial of service (DoS)\n\t\tin the access of shared resources. The system\n\t\tinterconnect might be left in an inconsistent state,\n\t\trequiring a partial or full reset of the network,\n\t\taccording to the implementation.  The scenario may\n\t\tplay out as follows. The interconnect receives a write\n\t\trequest from a controller initiator (e.g., sending the\n\t\theader to the interconnect for writing N words of\n\t\tdata, with N ranging from 1 to the maximum burst\n\t\tlength allowed). The interconnect then speculatively\n\t\tpropagates the request to the target peripheral\n\t\tthrough the shared bus before the corresponding data\n\t\tare received at the interconnect. Here, the word\n\t\t\"speculatively\" refers to the fact that the\n\t\tinterconnect propagates the request, assuming that the\n\t\tcontroller will at some point provide the data, thus\n\t\treleasing the use of the bus.  This speculatively\n\t\treserves the bus to the manager transaction issuer,\n\t\twhich is left free to delay its data provisioning\n\t\tphase.  This reserves the whole bus path between the\n\t\tinitiator and the target peripheral until all of the\n\t\twords associated with the request are provided by the\n\t\tcontroller.  If the interconnect assumes a cooperative\n\t\tbehavior from the controller, it is implicitly\n\t\ttrusting that the controller will complete the\n\t\ttransaction and release the bus for use from the other\n\t\tcontrollers. A malicious, faulty, or misbehaving\n\t\tmanager module can generate a denial-of-service\n\t\tcondition in preventing access to the write data link\n\t\tfrom all of the other managers in the system, and\n\t\tunboundedly inhibit the write access to one or\n\t\tmultiple peripherals in the system (i.e., memories,\n\t\tI/Os, etc.)."]}}}, "Detection_Methods": {"Detection_Method": [{"Method": "Architecture or Design Review", "Description": {"xhtml:p": "Instances of this issue can be detected by\n\t\tmanual review of the switching policy implemented in\n\t\tthe interconnect and the deployed on-chip\n\t\tcommunication standard.", "#text_blocks": ["Instances of this issue can be detected by\n\t\tmanual review of the switching policy implemented in\n\t\tthe interconnect and the deployed on-chip\n\t\tcommunication standard."]}, "Effectiveness": "Opportunistic", "Effectiveness_Notes": {"xhtml:p": "Manual review requires to have a full\n\t\tdescription of the architecture of the\n\t\tinterconnect. This information might not be available\n\t\twhen a third-party interconnect is used.", "#text_blocks": ["Manual review requires to have a full\n\t\tdescription of the architecture of the\n\t\tinterconnect. This information might not be available\n\t\twhen a third-party interconnect is used."]}}, {"Method": "Formal Verification", "Description": {"xhtml:p": "Instances of this issue can be found in\n\t\tmanager modules by using property-based verification\n\t\tspecifically targeting the detection of stalls\n\t\tpropagated to the shared resources\n\t\t[REF-1588].", "#text_blocks": ["Instances of this issue can be found in\n\t\tmanager modules by using property-based verification\n\t\tspecifically targeting the detection of stalls\n\t\tpropagated to the shared resources\n\t\t[REF-1588]."]}, "Effectiveness": "High"}, {"Method": "Simulation / Emulation", "Description": {"xhtml:p": "Instances of this issue can be found in\n\t\tsimulation by synthetically generating stalls at the\n\t\tinput of the interconnect and evaluating if the\n\t\tinterconnect propagates the stalls at the output or\n\t\tnot.", "#text_blocks": ["Instances of this issue can be found in\n\t\tsimulation by synthetically generating stalls at the\n\t\tinput of the interconnect and evaluating if the\n\t\tinterconnect propagates the stalls at the output or\n\t\tnot."]}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "Simulations should be capable of triggering\n\t\tthe stalls. Not all of the Verification IP for on-chip\n\t\tcommunications might be capable of triggering this\n\t\tissue.", "#text_blocks": ["Simulations should be capable of triggering\n\t\tthe stalls. Not all of the Verification IP for on-chip\n\t\tcommunications might be capable of triggering this\n\t\tissue."]}}]}, "Potential_Mitigations": {"Mitigation": {"Custom_Phase": [{"@Domain": "Hardware", "#text": "Hardware Architecture"}, {"@Domain": "Hardware", "#text": "Hardware Microarchitecture"}], "Description": {"xhtml:p": "SoC architects can use a switching\n\t\tmethodology stopping stalls from being propagated to\n\t\tthe interconnect, such as Cut-and-Forward\n\t\t[REF-1585][REF-1587] or\n\t\tStore-and-Forward. Alternatively, a monitoring and\n\t\trecovery module can be added between the interconnect\n\t\tand each manager module to detect stalls introduced by\n\t\tthe module and restore a safe state in the\n\t\tinterconnect after a stall has been detected\n\t\t[REF-1586].", "#text_blocks": ["SoC architects can use a switching\n\t\tmethodology stopping stalls from being propagated to\n\t\tthe interconnect, such as Cut-and-Forward\n\t\t[REF-1585][REF-1587] or\n\t\tStore-and-Forward. Alternatively, a monitoring and\n\t\trecovery module can be added between the interconnect\n\t\tand each manager module to detect stalls introduced by\n\t\tthe module and restore a safe state in the\n\t\tinterconnect after a stall has been detected\n\t\t[REF-1586]."]}, "Effectiveness": "High", "Effectiveness_Notes": {"xhtml:p": "The architect should evaluate which\n\t\tmethodology better suits the target platform, trading\n\t\toff performance and resource consumption impact\n\t\t[REF-1585][REF-1586][REF-1587].", "#text_blocks": ["The architect should evaluate which\n\t\tmethodology better suits the target platform, trading\n\t\toff performance and resource consumption impact\n\t\t[REF-1585][REF-1586][REF-1587]."]}}}, "Demonstrative_Examples": {"Demonstrative_Example": {"Intro_Text": {"xhtml:p": ["In a system-on-chip, multiple hardware\n\t\tcomponents may communicate with shared resources\n\t\tthrough an interconnect. A manager initiates\n\t\ttransactions, while a target is a shared resource such\n\t\tas memory or a peripheral. A shared write path is the\n\t\tportion of the interconnect used by multiple managers\n\t\tto send write data to the same target.", "To reduce buffering requirements and\n\t\tpropagation latency, an interconnect may use\n\t\tcut-through switching. In protocols where the write\n\t\trequest and corresponding write data are transferred\n\t\tindependently, the interconnect can forward the\n\t\trequest before all of the associated write data have\n\t\tarrived."], "#text_blocks": ["In a system-on-chip, multiple hardware\n\t\tcomponents may communicate with shared resources\n\t\tthrough an interconnect. A manager initiates\n\t\ttransactions, while a target is a shared resource such\n\t\tas memory or a peripheral. A shared write path is the\n\t\tportion of the interconnect used by multiple managers\n\t\tto send write data to the same target.", "To reduce buffering requirements and\n\t\tpropagation latency, an interconnect may use\n\t\tcut-through switching. In protocols where the write\n\t\trequest and corresponding write data are transferred\n\t\tindependently, the interconnect can forward the\n\t\trequest before all of the associated write data have\n\t\tarrived."]}, "Body_Text": [{"xhtml:img": {"@src": "/data/images/CWE-1476-cut-through.png", "@alt": "cut-through diagram"}, "#text_blocks": []}, {"xhtml:ul": {"xhtml:li": ["(a) Manager A issues a multi-word write\n\t\t  request.", "(b) The interconnect forwards the request\n\t\t  to the shared target before receiving all\n\t\t  corresponding write data. The shared write path is\n\t\t  reserved for Manager A until its data transfer\n\t\t  completes.", "(c) Manager A delays or stops sending the\n\t\t  remaining data. The transaction remains incomplete,\n\t\t  and the shared write path remains\n\t\t  reserved.", "(d) Manager B attempts to use the same shared path but cannot proceed\n\t\t  until Manager A completes the data transfer or a recovery mechanism\n\t\t  safely releases the path."]}, "xhtml:p": "In these diagrams, \"reserved\" refers to the\n\t\tshared write path serving the target, rather than\n\t\tevery operation or route to that target.", "#text_blocks": ["(a) Manager A issues a multi-word write\n\t\t  request.", "(b) The interconnect forwards the request\n\t\t  to the shared target before receiving all\n\t\t  corresponding write data. The shared write path is\n\t\t  reserved for Manager A until its data transfer\n\t\t  completes.", "(c) Manager A delays or stops sending the\n\t\t  remaining data. The transaction remains incomplete,\n\t\t  and the shared write path remains\n\t\t  reserved.", "(d) Manager B attempts to use the same shared path but cannot proceed\n\t\t  until Manager A completes the data transfer or a recovery mechanism\n\t\t  safely releases the path.", "In these diagrams, \"reserved\" refers to the\n\t\tshared write path serving the target, rather than\n\t\tevery operation or route to that target."]}, {"xhtml:p": "The interconnect reserves the shared\n\t      write path before the data required to complete the\n\t      transaction are available. In the problematic design\n\t      shown here, other managers cannot use that shared write\n\t      path until the corresponding data transfer\n\t      completes. Thus, the interconnect depends on Manager A\n\t      to continue making forward progress. If Manager A\n\t      stalls, the stall propagates into the shared portion of\n\t      the interconnect and prevents competing transactions\n\t      from using that shared write path.", "#text_blocks": ["The interconnect reserves the shared\n\t      write path before the data required to complete the\n\t      transaction are available. In the problematic design\n\t      shown here, other managers cannot use that shared write\n\t      path until the corresponding data transfer\n\t      completes. Thus, the interconnect depends on Manager A\n\t      to continue making forward progress. If Manager A\n\t      stalls, the stall propagates into the shared portion of\n\t      the interconnect and prevents competing transactions\n\t      from using that shared write path."]}, {"xhtml:p": "One approach is store-and-forward switching the\n\t\tinterconnect buffers the request and all corresponding\n\t\twrite data before forwarding the request, preventing a\n\t\tmanager's input-side stall from propagating into the\n\t\tshared write path. If Manager A delays or stops sending\n\t\tdata, its incomplete transaction remains in the input\n\t\tbuffer, and the shared write path remains available to\n\t\ttransactions from other managers.", "#text_blocks": ["One approach is store-and-forward switching the\n\t\tinterconnect buffers the request and all corresponding\n\t\twrite data before forwarding the request, preventing a\n\t\tmanager's input-side stall from propagating into the\n\t\tshared write path. If Manager A delays or stops sending\n\t\tdata, its incomplete transaction remains in the input\n\t\tbuffer, and the shared write path remains available to\n\t\ttransactions from other managers."]}, {"xhtml:img": {"@src": "/data/images/CWE-1476-store-and-forward-1.png", "@alt": "store-and-forward diagram"}, "#text_blocks": []}, {"xhtml:ul": {"xhtml:li": ["(a) Manager A issues a multi-word write\n\t\t  request.", "(b) The interconnect buffers the request\n\t\t  and waits for all corresponding write data. The\n\t\t  request has not been forwarded, and the shared write\n\t\t  path is not yet reserved for Manager A.", "(c) After all data have been received and\n\t\t  buffered, the interconnect forwards the request to\n\t\t  the shared target.", "(d) The interconnect forwards the buffered\n\t\t  data without waiting for additional data from\n\t\t  Manager A. Completion of the data transfer releases\n\t\t  the shared write path. The target completes the\n\t\t  write and returns a response through the\n\t\t  interconnect to Manager A."]}, "#text_blocks": ["(a) Manager A issues a multi-word write\n\t\t  request.", "(b) The interconnect buffers the request\n\t\t  and waits for all corresponding write data. The\n\t\t  request has not been forwarded, and the shared write\n\t\t  path is not yet reserved for Manager A.", "(c) After all data have been received and\n\t\t  buffered, the interconnect forwards the request to\n\t\t  the shared target.", "(d) The interconnect forwards the buffered\n\t\t  data without waiting for additional data from\n\t\t  Manager A. Completion of the data transfer releases\n\t\t  the shared write path. The target completes the\n\t\t  write and returns a response through the\n\t\t  interconnect to Manager A."]}, {"xhtml:p": "Store-and-forward requires storage for an\n\t\tentire transaction, increasing buffer capacity and\n\t\thardware area. It also adds buffering latency because\n\t\tforwarding begins only after all corresponding data\n\t\thave arrived. [REF-1585]", "#text_blocks": ["Store-and-forward requires storage for an\n\t\tentire transaction, increasing buffer capacity and\n\t\thardware area. It also adds buffering latency because\n\t\tforwarding begins only after all corresponding data\n\t\thave arrived. [REF-1585]"]}, {"xhtml:img": {"@src": "/data/images/CWE-1476-cut-and-forward-2.png", "@alt": "cut-and-forward diagram"}, "#text_blocks": []}, {"xhtml:ul": {"xhtml:li": ["(a) Manager A issues a four-word write\n\t\t  request.", "(b) The interconnect buffers the request\n\t\t  and begins receiving the corresponding write\n\t\t  data. The request has not been forwarded, so the\n\t\t  shared write path is not yet reserved for this\n\t\t  transaction.", "(c) After the first two words have been\n\t\t  buffered, the interconnect creates a two-word write\n\t\t  request and forwards it with the complete first\n\t\t  chunk to the shared target. While forwarding this\n\t\t  chunk, the interconnect can receive and buffer the\n\t\t  next two words.", "(d) After the remaining two words have\n\t\t  been buffered, the interconnect creates and forwards\n\t\t  a second two-word write transaction with the\n\t\t  complete second chunk.", "(e) The shared target completes the two\n\t\t  shorter transactions and returns a separate response\n\t\t  for each one.", "(f) The interconnect waits for both\n\t\t  responses, combines them into the single response\n\t\t  expected for the original transaction, and returns\n\t\t  that response to Manager A."]}, "#text_blocks": ["(a) Manager A issues a four-word write\n\t\t  request.", "(b) The interconnect buffers the request\n\t\t  and begins receiving the corresponding write\n\t\t  data. The request has not been forwarded, so the\n\t\t  shared write path is not yet reserved for this\n\t\t  transaction.", "(c) After the first two words have been\n\t\t  buffered, the interconnect creates a two-word write\n\t\t  request and forwards it with the complete first\n\t\t  chunk to the shared target. While forwarding this\n\t\t  chunk, the interconnect can receive and buffer the\n\t\t  next two words.", "(d) After the remaining two words have\n\t\t  been buffered, the interconnect creates and forwards\n\t\t  a second two-word write transaction with the\n\t\t  complete second chunk.", "(e) The shared target completes the two\n\t\t  shorter transactions and returns a separate response\n\t\t  for each one.", "(f) The interconnect waits for both\n\t\t  responses, combines them into the single response\n\t\t  expected for the original transaction, and returns\n\t\t  that response to Manager A."]}, {"xhtml:p": "The shared write path is reserved only when a\n\t\tcomplete chunk is ready. If Manager A delays data for\n\t\ta later chunk, the incomplete chunk remains in the\n\t\tinput buffer; the path is not held while waiting for\n\t\tthose data and remains available to other\n\t\tmanagers. Smaller chunks reduce buffering requirements\n\t\tand forwarding delay but increase target-side\n\t\ttransaction and response overhead. Larger chunks\n\t\treduce that overhead but require more buffering and\n\t\tincrease the delay before forwarding\n\t\tbegins. [REF-1585]", "#text_blocks": ["The shared write path is reserved only when a\n\t\tcomplete chunk is ready. If Manager A delays data for\n\t\ta later chunk, the incomplete chunk remains in the\n\t\tinput buffer; the path is not held while waiting for\n\t\tthose data and remains available to other\n\t\tmanagers. Smaller chunks reduce buffering requirements\n\t\tand forwarding delay but increase target-side\n\t\ttransaction and response overhead. Larger chunks\n\t\treduce that overhead but require more buffering and\n\t\tincrease the delay before forwarding\n\t\tbegins. [REF-1585]"]}, {"xhtml:p": "The behavior illustrated here has been\n\t\tdemonstrated in AXI-based interconnects. The weakness\n\t\tis not inherently specific to AXI and can arise in\n\t\tother interconnect protocols with equivalent\n\t\trequest/data separation, ordering,\n\t\tresource-commitment, and progress properties. The\n\t\tdiagrams omit signal-level details to focus on the\n\t\tshared write path and transaction\n\t\tsequence. [REF-1585][REF-1586]", "#text_blocks": ["The behavior illustrated here has been\n\t\tdemonstrated in AXI-based interconnects. The weakness\n\t\tis not inherently specific to AXI and can arise in\n\t\tother interconnect protocols with equivalent\n\t\trequest/data separation, ordering,\n\t\tresource-commitment, and progress properties. The\n\t\tdiagrams omit signal-level details to focus on the\n\t\tshared write path and transaction\n\t\tsequence. [REF-1585][REF-1586]"]}], "Example_Code": [{"@Nature": "Attack", "xhtml:p": "A faulty or malicious manager can delay or\n\t\tstop providing the remaining write data. If the\n\t\tinterconnect does not enforce bounded progress or\n\t\tprovide a recovery mechanism, the manager can hold the\n\t\tshared write path indefinitely and cause a denial of\n\t\tservice for competing write transactions that require\n\t\tthe same shared write path.", "#text_blocks": ["A faulty or malicious manager can delay or\n\t\tstop providing the remaining write data. If the\n\t\tinterconnect does not enforce bounded progress or\n\t\tprovide a recovery mechanism, the manager can hold the\n\t\tshared write path indefinitely and cause a denial of\n\t\tservice for competing write transactions that require\n\t\tthe same shared write path."]}, {"@Nature": "Good", "@Language": "Other", "xhtml:p": "The interconnect should avoid reserving the\n\t\tshared write path until the data needed to complete\n\t\tthe forwarded transaction are available.", "#text_blocks": ["The interconnect should avoid reserving the\n\t\tshared write path until the data needed to complete\n\t\tthe forwarded transaction are available."]}, {"@Nature": "Good", "@Language": "Other", "xhtml:p": ["Cut-and-forward is a second preventive approach. It divides a\n\t\ttransaction into smaller transactions and forwards each only after all\n\t\tdata for that chunk have been buffered. Like store-and-forward, it\n\t\tprevents a manager's data-provisioning stall from reserving the shared\n\t\twrite path. [REF-1585]", "Cut-and-forward applies the same principle at a smaller chunk\n\t\tgranularity.  In Figure 3, a four-word write is divided into two\n\t\tchunks of two words each. The interconnect creates the shorter\n\t\ttransactions and combines their responses, so Manager A continues to\n\t\tissue and receive a response for the original transaction. [REF-1585]"], "#text_blocks": ["Cut-and-forward is a second preventive approach. It divides a\n\t\ttransaction into smaller transactions and forwards each only after all\n\t\tdata for that chunk have been buffered. Like store-and-forward, it\n\t\tprevents a manager's data-provisioning stall from reserving the shared\n\t\twrite path. [REF-1585]", "Cut-and-forward applies the same principle at a smaller chunk\n\t\tgranularity.  In Figure 3, a four-word write is divided into two\n\t\tchunks of two words each. The interconnect creates the shorter\n\t\ttransactions and combines their responses, so Manager A continues to\n\t\tissue and receive a response for the original transaction. [REF-1585]"]}, {"@Nature": "Good", "@Language": "Other", "xhtml:p": "A watchdog with protocol-aware recovery is a third,\n\t\tseparate mitigation approach. It limits the duration\n\t\tof a stall by restoring the shared path to a usable\n\t\tstate. It does not prevent the stall from entering the\n\t\tshared path: other managers may remain blocked until\n\t\tdetection and recovery complete. Detection alone does\n\t\tnot release the path. [REF-1586]", "#text_blocks": ["A watchdog with protocol-aware recovery is a third,\n\t\tseparate mitigation approach. It limits the duration\n\t\tof a stall by restoring the shared path to a usable\n\t\tstate. It does not prevent the stall from entering the\n\t\tshared path: other managers may remain blocked until\n\t\tdetection and recovery complete. Detection alone does\n\t\tnot release the path. [REF-1586]"]}]}}, "Observed_Examples": {"Observed_Example": {"Reference": "[REF-1586]", "Description": "Certain commercial AXI interconnect IPs\n\t      could allow a manager to cause bus stalls.", "Link": "https://ieeexplore.ieee.org/abstract/document/9114758"}}, "References": {"Reference": [{"@External_Reference_ID": "REF-1585"}, {"@External_Reference_ID": "REF-1586"}, {"@External_Reference_ID": "REF-1587"}, {"@External_Reference_ID": "REF-1588"}]}, "Mapping_Notes": {"Usage": "Allowed", "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.", "Reasons": {"Reason": {"@Type": "Acceptable-Use"}}}, "Content_History": {"Submission": {"Submission_Name": "Francesco Restuccia", "Submission_Organization": "University of California San Diego", "Submission_Date": "2022-08-25", "Submission_Version": "5.0", "Submission_ReleaseDate": "2026-10-28"}}, "entry_type": "Weakness"}