{"@ID": "1429", "@Name": "Missing Security-Relevant Feedback for Unexecuted Operations in Hardware Interface", "@Abstraction": "Base", "@Structure": "Simple", "@Status": "Incomplete", "Description": "The product has a hardware interface that silently discards operations\n\t\t\tin situations for which feedback would be security-relevant, such as\n\t\t\tthe timely detection of failures or attacks.", "Extended_Description": {"xhtml:p": ["While some systems intentionally withhold feedback as a security\n\t\t\t  measure, this approach must be strictly controlled to ensure it does\n\t\t\t  not obscure operational failures that require prompt detection and\n\t\t\t  remediation.  Without these essential confirmations, failures go\n\t\t\t  undetected, increasing the risk of data loss, security\n\t\t\t  vulnerabilities, and overall system instability. Even when withholding\n\t\t\t  feedback is an intentional part of a security policy designed, for\n\t\t\t  example, to prevent attackers from gleaning sensitive internal\n\t\t\t  details, the absence of expected feedback becomes a critical weakness\n\t\t\t  when it masks operational failures that require prompt detection and\n\t\t\t  remediation.", "For instance, certain encryption algorithms always return ciphertext\n\t\t\t  regardless of errors to prevent attackers from gaining insight into\n\t\t\t  internal state details. However, if such an algorithm fails to\n\t\t\t  generate the expected ciphertext and provides no error feedback, the\n\t\t\t  system cannot distinguish between a legitimate output and a\n\t\t\t  malfunction. This can lead to undetected cryptographic failures,\n\t\t\t  potentially compromising data security and system reliability. Without\n\t\t\t  proper notification, a critical failure might remain hidden,\n\t\t\t  undermining both the reliability and security of the process.", "Therefore, this weakness captures issues across various hardware\n\t\t\t  interfaces where operations are discarded without any feedback, error\n\t\t\t  handling, or logging. Such omissions can lead to data loss, security\n\t\t\t  vulnerabilities, and system instability, with potential impacts\n\t\t\t  ranging from minor to catastrophic.", "For some kinds of hardware products, some errors may be correctly\n\t\t\t  identified and subsequently discarded, and the lack of feedback may\n\t\t\t  have been an intentional design decision. However, this could result\n\t\t\t  in a weakness if system operators or other authorized entities are not\n\t\t\t  provided feedback about security-critical operations or failures that\n\t\t\t  could prevent the operators from detecting and responding to an\n\t\t\t  attack.", "For example:"], "xhtml:ul": {"xhtml:li": ["In a System-on-Chip (SoC) platform, write operations to reserved\n\t\t\t    memory addresses might be correctly identified as invalid and\n\t\t\t    subsequently discarded. However, if no feedback is provided to\n\t\t\t    system operators, they may misinterpret the device's state, failing\n\t\t\t    to recognize conditions that could lead to broader failures or\n\t\t\t    security vulnerabilities. For example, if an attacker attempts\n\t\t\t    unauthorized writes to protected regions, the system may silently\n\t\t\t    discard these writes without alerting security mechanisms. This lack\n\t\t\t    of feedback could obscure intrusion attempts or misconfigurations,\n\t\t\t    increasing the risk of unnoticed system compromise", "Microcontroller Interrupt Systems: When interrupts are silently\n\t\t\t    ignored due to priority conflicts or internal errors without\n\t\t\t    notifying higher-level control, it becomes challenging to diagnose\n\t\t\t    system failures or detect potential security breaches in a timely\n\t\t\t    manner.", "Network Interface Controllers: Dropping packets - perhaps due to\n\t\t\t    buffer overflows - without any error feedback can not only cause data\n\t\t\t    loss but may also contribute to exploitable timing discrepancies\n\t\t\t    that reveal sensitive internal processing details."]}, "#text_blocks": ["While some systems intentionally withhold feedback as a security\n\t\t\t  measure, this approach must be strictly controlled to ensure it does\n\t\t\t  not obscure operational failures that require prompt detection and\n\t\t\t  remediation.  Without these essential confirmations, failures go\n\t\t\t  undetected, increasing the risk of data loss, security\n\t\t\t  vulnerabilities, and overall system instability. Even when withholding\n\t\t\t  feedback is an intentional part of a security policy designed, for\n\t\t\t  example, to prevent attackers from gleaning sensitive internal\n\t\t\t  details, the absence of expected feedback becomes a critical weakness\n\t\t\t  when it masks operational failures that require prompt detection and\n\t\t\t  remediation.", "For instance, certain encryption algorithms always return ciphertext\n\t\t\t  regardless of errors to prevent attackers from gaining insight into\n\t\t\t  internal state details. However, if such an algorithm fails to\n\t\t\t  generate the expected ciphertext and provides no error feedback, the\n\t\t\t  system cannot distinguish between a legitimate output and a\n\t\t\t  malfunction. This can lead to undetected cryptographic failures,\n\t\t\t  potentially compromising data security and system reliability. Without\n\t\t\t  proper notification, a critical failure might remain hidden,\n\t\t\t  undermining both the reliability and security of the process.", "Therefore, this weakness captures issues across various hardware\n\t\t\t  interfaces where operations are discarded without any feedback, error\n\t\t\t  handling, or logging. Such omissions can lead to data loss, security\n\t\t\t  vulnerabilities, and system instability, with potential impacts\n\t\t\t  ranging from minor to catastrophic.", "For some kinds of hardware products, some errors may be correctly\n\t\t\t  identified and subsequently discarded, and the lack of feedback may\n\t\t\t  have been an intentional design decision. However, this could result\n\t\t\t  in a weakness if system operators or other authorized entities are not\n\t\t\t  provided feedback about security-critical operations or failures that\n\t\t\t  could prevent the operators from detecting and responding to an\n\t\t\t  attack.", "For example:", "In a System-on-Chip (SoC) platform, write operations to reserved\n\t\t\t    memory addresses might be correctly identified as invalid and\n\t\t\t    subsequently discarded. However, if no feedback is provided to\n\t\t\t    system operators, they may misinterpret the device's state, failing\n\t\t\t    to recognize conditions that could lead to broader failures or\n\t\t\t    security vulnerabilities. For example, if an attacker attempts\n\t\t\t    unauthorized writes to protected regions, the system may silently\n\t\t\t    discard these writes without alerting security mechanisms. This lack\n\t\t\t    of feedback could obscure intrusion attempts or misconfigurations,\n\t\t\t    increasing the risk of unnoticed system compromise", "Microcontroller Interrupt Systems: When interrupts are silently\n\t\t\t    ignored due to priority conflicts or internal errors without\n\t\t\t    notifying higher-level control, it becomes challenging to diagnose\n\t\t\t    system failures or detect potential security breaches in a timely\n\t\t\t    manner.", "Network Interface Controllers: Dropping packets - perhaps due to\n\t\t\t    buffer overflows - without any error feedback can not only cause data\n\t\t\t    loss but may also contribute to exploitable timing discrepancies\n\t\t\t    that reveal sensitive internal processing details."]}, "Related_Weaknesses": {"Related_Weakness": [{"@Nature": "ChildOf", "@CWE_ID": "223", "@View_ID": "1000", "@Ordinal": "Primary"}, {"@Nature": "PeerOf", "@CWE_ID": "392", "@View_ID": "1000", "@Ordinal": "Primary"}]}, "Weakness_Ordinalities": {"Weakness_Ordinality": {"Ordinality": "Primary"}}, "Applicable_Platforms": {"Language": [{"@Name": "C", "@Prevalence": "Undetermined"}, {"@Name": "C++", "@Prevalence": "Undetermined"}, {"@Name": "Verilog", "@Prevalence": "Undetermined"}, {"@Class": "Hardware Description Language", "@Prevalence": "Undetermined"}, {"@Class": "Not Language-Specific", "@Prevalence": "Undetermined"}], "Architecture": [{"@Name": "ARM", "@Prevalence": "Undetermined"}, {"@Name": "x86", "@Prevalence": "Undetermined"}, {"@Class": "Embedded", "@Prevalence": "Undetermined"}], "Technology": [{"@Name": "Security Hardware", "@Prevalence": "Undetermined"}, {"@Name": "Processor Hardware", "@Prevalence": "Undetermined"}, {"@Name": "Microcontroller Hardware", "@Prevalence": "Undetermined"}, {"@Class": "System on Chip", "@Prevalence": "Undetermined"}]}, "Modes_Of_Introduction": {"Introduction": [{"Phase": "Architecture and Design", "Note": {"xhtml:p": "This weakness can be introduced during the architecture and\ndesign phase when the system does not incorporate proper mechanisms\nfor error reporting or feedback for discarded operations, such as when\nhandling reserved addresses or unexecuted instructions.", "#text_blocks": ["This weakness can be introduced during the architecture and\ndesign phase when the system does not incorporate proper mechanisms\nfor error reporting or feedback for discarded operations, such as when\nhandling reserved addresses or unexecuted instructions."]}}, {"Phase": "Implementation", "Note": {"xhtml:p": "It can also arise during implementation if developers fail to\ninclude appropriate feedback or logging for critical operations. This\nleads to silent failures in certain scenarios like interrupt handling\nor network buffer overflows.", "#text_blocks": ["It can also arise during implementation if developers fail to\ninclude appropriate feedback or logging for critical operations. This\nleads to silent failures in certain scenarios like interrupt handling\nor network buffer overflows."]}}, {"Phase": "Requirements", "Note": {"xhtml:p": "A further layer of complexity emerges when considering\nspecifications. The weakness may stem either from ambiguous product\ndesign specifications that fail to delineate when feedback should\noccur or from implementations that do not adhere to existing\nrequirements. In either case, the result is the same: feedback that is\ncritical for detecting operational failures or security breaches is\nmissing.", "#text_blocks": ["A further layer of complexity emerges when considering\nspecifications. The weakness may stem either from ambiguous product\ndesign specifications that fail to delineate when feedback should\noccur or from implementations that do not adhere to existing\nrequirements. In either case, the result is the same: feedback that is\ncritical for detecting operational failures or security breaches is\nmissing."]}}]}, "Common_Consequences": {"Consequence": [{"Scope": "Confidentiality", "Impact": ["Read Memory", "Read Files or Directories"], "Likelihood": "Medium", "Note": {"xhtml:p": "Critical data may be exposed if operations are unexecuted or\n\t\t\t\tdiscarded silently, allowing attackers to exploit the lack of\n\t\t\t\tfeedback.", "#text_blocks": ["Critical data may be exposed if operations are unexecuted or\n\t\t\t\tdiscarded silently, allowing attackers to exploit the lack of\n\t\t\t\tfeedback."]}}, {"Scope": "Integrity", "Impact": ["Modify Memory", "Modify Files or Directories"], "Likelihood": "Medium", "Note": {"xhtml:p": "Operations may proceed based on incorrect assumptions,\n\t\t\t\tpotentially causing data corruption or incorrect system behavior. In\n\t\t\t\tintegrity-sensitive contexts, failing to signal that an operation did\n\t\t\t\tnot occur as expected can mask errors that disrupt data\n\t\t\t\tconsistency. Without feedback, the mitigation measures that should\n\t\t\t\tensure updates have been performed cannot be verified, leaving the\n\t\t\t\tsystem vulnerable to both accidental and malicious data alterations.", "#text_blocks": ["Operations may proceed based on incorrect assumptions,\n\t\t\t\tpotentially causing data corruption or incorrect system behavior. In\n\t\t\t\tintegrity-sensitive contexts, failing to signal that an operation did\n\t\t\t\tnot occur as expected can mask errors that disrupt data\n\t\t\t\tconsistency. Without feedback, the mitigation measures that should\n\t\t\t\tensure updates have been performed cannot be verified, leaving the\n\t\t\t\tsystem vulnerable to both accidental and malicious data alterations."]}}, {"Scope": "Availability", "Impact": ["DoS: Resource Consumption (Memory)", "DoS: Crash, Exit, or Restart"], "Likelihood": "High", "Note": {"xhtml:p": "Unhandled discarded operations can lead to resource exhaustion,\n\t\t\t\ttriggering system crashes or denial of service.  For availability,\n\t\t\t\tconsistent feedback is crucial. Without proper notification of\n\t\t\t\tdiscarded operations, administrators or other authorized entities\n\t\t\t\tmight miss early warning signs of resource imbalances. This delayed\n\t\t\t\tdetection could allow a DoS condition to develop, compromising the\n\t\t\t\tsystem's ability to serve legitimate requests and maintain continuous\n\t\t\t\toperations.", "#text_blocks": ["Unhandled discarded operations can lead to resource exhaustion,\n\t\t\t\ttriggering system crashes or denial of service.  For availability,\n\t\t\t\tconsistent feedback is crucial. Without proper notification of\n\t\t\t\tdiscarded operations, administrators or other authorized entities\n\t\t\t\tmight miss early warning signs of resource imbalances. This delayed\n\t\t\t\tdetection could allow a DoS condition to develop, compromising the\n\t\t\t\tsystem's ability to serve legitimate requests and maintain continuous\n\t\t\t\toperations."]}}]}, "Detection_Methods": {"Detection_Method": [{"Method": "Automated Static Analysis - Source Code", "Description": {"xhtml:p": "Scans code for missing error handling or feedback mechanisms.", "#text_blocks": ["Scans code for missing error handling or feedback mechanisms."]}, "Effectiveness": "High", "Effectiveness_Notes": {"xhtml:p": "This identifies common issues early in the development phase.", "#text_blocks": ["This identifies common issues early in the development phase."]}}, {"Method": "Manual Static Analysis - Source Code", "Description": {"xhtml:p": "Experts manually inspect the code for unhandled operations.", "#text_blocks": ["Experts manually inspect the code for unhandled operations."]}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "Useful for identifying design-level omissions.", "#text_blocks": ["Useful for identifying design-level omissions."]}}]}, "Potential_Mitigations": {"Mitigation": [{"Phase": "Architecture and Design", "Description": {"xhtml:p": "Incorporate logging and feedback mechanisms during the\n\t\t\t\tdesign phase to ensure proper handling of discarded operations.", "#text_blocks": ["Incorporate logging and feedback mechanisms during the\n\t\t\t\tdesign phase to ensure proper handling of discarded operations."]}, "Effectiveness": "High", "Effectiveness_Notes": {"xhtml:p": "Addressing the issue at the design stage prevents\n\t\t\t\tthe weakness from manifesting later.", "#text_blocks": ["Addressing the issue at the design stage prevents\n\t\t\t\tthe weakness from manifesting later."]}}, {"Phase": "Implementation", "Description": {"xhtml:p": "Developers should ensure that every critical operation\n\t\t\t\tincludes proper logging or error feedback mechanisms.", "#text_blocks": ["Developers should ensure that every critical operation\n\t\t\t\tincludes proper logging or error feedback mechanisms."]}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "Implementation-level checks complement\n\t\t\t\tdesign-phase measures.", "#text_blocks": ["Implementation-level checks complement\n\t\t\t\tdesign-phase measures."]}}]}, "Demonstrative_Examples": {"Demonstrative_Example": [{"Intro_Text": {"xhtml:p": "This code creates an interrupt handler.  If the interrupt's priority\nis lower than the currently active one, the interrupt is discarded\nwithout any feedback, perhaps due to resource constraints.", "#text_blocks": ["This code creates an interrupt handler.  If the interrupt's priority\nis lower than the currently active one, the interrupt is discarded\nwithout any feedback, perhaps due to resource constraints."]}, "Example_Code": [{"@Nature": "Bad", "@Language": "C", "xhtml:br": [null, null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": [null, null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": null, "#text": "return;"}, "#text": "if (irq_priority[irq] < current_priority) {\n\t\t\t\t\t\t\n\t\t\t\t\t\t}\n\t\t\t\t\t\tprocess_interrupt(irq);"}, "#text": "void interrupt_handler(int irq) {\n\t\t\t\t\t  \n\t\t\t\t\t  }", "#text_blocks": ["void interrupt_handler(int irq) {", "if (irq_priority[irq] < current_priority) {", "return;", "}", "process_interrupt(irq);", "}"]}, {"@Nature": "Good", "@Language": "C", "xhtml:br": [null, null, null, null, null, null, null, null], "xhtml:div": [{"@style": "margin-left:1em;", "xhtml:br": null, "#text": "printf(\"Processing interrupt %d\\n\", irq);"}, {"@style": "margin-left:1em;", "xhtml:br": [null, null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": [null, null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": null, "#text": "irq, irq_priority[irq], current_priority);"}, "#text": "// Log the dropped interrupt using structured feedback\n\t\t\t\t\t\t  fprintf(stderr, \"Warning: Interrupt %d dropped (Priority: %d < Current: %d)\\n\", \n\t\t\t\t\t\t  \n\t\t\t\t\t\t  exit(EXIT_FAILURE);  // Exit with failure status to indicate a critical issue."}, "#text": "if (irq_priority[irq] < current_priority) {\n\t\t\t\t\t\t\n\t\t\t\t\t\t}\n\t\t\t\t\t\tprocess_interrupt(irq);"}], "#text": "// Priority threshold for active interrupts\n\t\t\t\t\t  int current_priority = 3;\n\t\t\t\t\t  // Simulated priority levels for different IRQs\n\t\t\t\t\t  int irq_priority[5] = {1, 2, 3, 4, 5};\n\t\t\t\t\t  void process_interrupt(int irq) {\n\t\t\t\t\t  \n\t\t\t\t\t  }\n\t\t\t\t\t  void interrupt_handler(int irq) {\n\t\t\t\t\t  \n\t\t\t\t\t  }", "#text_blocks": ["// Priority threshold for active interrupts", "int current_priority = 3;", "// Simulated priority levels for different IRQs", "int irq_priority[5] = {1, 2, 3, 4, 5};", "void process_interrupt(int irq) {", "printf(\"Processing interrupt %d\\n\", irq);", "}", "void interrupt_handler(int irq) {", "if (irq_priority[irq] < current_priority) {", "// Log the dropped interrupt using structured feedback", "fprintf(stderr, \"Warning: Interrupt %d dropped (Priority: %d < Current: %d)\\n\",", "irq, irq_priority[irq], current_priority);", "exit(EXIT_FAILURE);  // Exit with failure status to indicate a critical issue.", "}", "process_interrupt(irq);", "}"]}], "Body_Text": {"xhtml:p": ["The omission of feedback for the dropped lower-priority interrupt can\n\t\t\t\t\tcause developers to misinterpret the state of the system, leading to\n\t\t\t\t\tincorrect assumptions and potential system failures, such as missed\n\t\t\t\t\tsensor readings.", "Attackers might leverage this lack of visibility to induce conditions\n\t\t\t\t\tthat lead to timing side-channels. For example, an attacker could\n\t\t\t\t\tintentionally flood the system with high-priority interrupts, forcing\n\t\t\t\t\tthe system to discard lower-priority interrupts consistently. If these\n\t\t\t\t\tdiscarded interrupts correspond to processes executing critical\n\t\t\t\t\tsecurity functions (e.g., cryptographic key handling), an attacker\n\t\t\t\t\tmight measure system timing variations to infer when and how those\n\t\t\t\t\tfunctions are executing. This creates a timing side channel that could\n\t\t\t\t\tbe used to extract sensitive information. Moreover, since these\n\t\t\t\t\tlower-priority interrupts are not reported, the system remains unaware\n\t\t\t\t\tthat critical tasks such as sensor data collection or maintenance\n\t\t\t\t\troutines, are being starved of execution. Over time, this can lead to\n\t\t\t\t\tfunctional failures or watchdog time resets in real-time systems.", "One way to address this problem could be to use structured logging to\n\t\t\t\t\tprovide visibility into discarded interrupts. This allows\n\t\t\t\t\tadministrators, developers, or other authorized entities to track\n\t\t\t\t\tmissed interrupts and optimize the system."], "#text_blocks": ["The omission of feedback for the dropped lower-priority interrupt can\n\t\t\t\t\tcause developers to misinterpret the state of the system, leading to\n\t\t\t\t\tincorrect assumptions and potential system failures, such as missed\n\t\t\t\t\tsensor readings.", "Attackers might leverage this lack of visibility to induce conditions\n\t\t\t\t\tthat lead to timing side-channels. For example, an attacker could\n\t\t\t\t\tintentionally flood the system with high-priority interrupts, forcing\n\t\t\t\t\tthe system to discard lower-priority interrupts consistently. If these\n\t\t\t\t\tdiscarded interrupts correspond to processes executing critical\n\t\t\t\t\tsecurity functions (e.g., cryptographic key handling), an attacker\n\t\t\t\t\tmight measure system timing variations to infer when and how those\n\t\t\t\t\tfunctions are executing. This creates a timing side channel that could\n\t\t\t\t\tbe used to extract sensitive information. Moreover, since these\n\t\t\t\t\tlower-priority interrupts are not reported, the system remains unaware\n\t\t\t\t\tthat critical tasks such as sensor data collection or maintenance\n\t\t\t\t\troutines, are being starved of execution. Over time, this can lead to\n\t\t\t\t\tfunctional failures or watchdog time resets in real-time systems.", "One way to address this problem could be to use structured logging to\n\t\t\t\t\tprovide visibility into discarded interrupts. This allows\n\t\t\t\t\tadministrators, developers, or other authorized entities to track\n\t\t\t\t\tmissed interrupts and optimize the system."]}}, {"Intro_Text": {"xhtml:p": ["Consider a SoC design with these component IPs:", "IP 1. Execution Core  <--> IP 2 SoC Fabric (NoC, tile etc. )  <--> IP 3 Memory Controller  <--> External/ internal memory.", "The Core executes operations that trigger transactions that traverse\n\t\t\t\t  the HW fabric links to read/write to the final memory module.", "There can be unexpected errors in each link. For adding reliability\n\t\t\t\t  and redundancy, features like ECCs are used in these\n\t\t\t\t  transactions. Error correction capabilities have to define how many\n\t\t\t\t  error bits can be detected and which errors can be corrected, and\n\t\t\t\t  which are uncorrectable errors. In design, often the severity level\n\t\t\t\t  and response on different errors is allowed to be configured by system\n\t\t\t\t  firmware modules like BIOS."], "#text_blocks": ["Consider a SoC design with these component IPs:", "IP 1. Execution Core  <--> IP 2 SoC Fabric (NoC, tile etc. )  <--> IP 3 Memory Controller  <--> External/ internal memory.", "The Core executes operations that trigger transactions that traverse\n\t\t\t\t  the HW fabric links to read/write to the final memory module.", "There can be unexpected errors in each link. For adding reliability\n\t\t\t\t  and redundancy, features like ECCs are used in these\n\t\t\t\t  transactions. Error correction capabilities have to define how many\n\t\t\t\t  error bits can be detected and which errors can be corrected, and\n\t\t\t\t  which are uncorrectable errors. In design, often the severity level\n\t\t\t\t  and response on different errors is allowed to be configured by system\n\t\t\t\t  firmware modules like BIOS."]}, "Example_Code": [{"@Nature": "Bad", "@Language": "Other", "#text": "If an uncorrectable error occurs, the design does not explicitly\n\t\t\t\t\ttrigger an alert back to the execution core."}, {"@Nature": "Good", "@Language": "Other", "#text": "Modify the design so that any uncorrectable error triggers an alert\n\t\t\t\t\tback to the execution core and gets handled before the core can\n\t\t\t\t\tconsume the data read/written through the corrupted transactions.\n\t\t\t\t\tUpdate design access control policies to ensure that alerts sent to\n\t\t\t\t\texecution core on uncorrectable errors cannot be disabled or masked by\n\t\t\t\t\tuntrusted software/firmware."}], "Body_Text": {"xhtml:p": ["For system security, if an uncorrectable error occurs but is not\n\t\t\t\t  reported to the execution core and handled before the core attempts to\n\t\t\t\t  consume the data that is read/written through the corrupted\n\t\t\t\t  transactions, then this could enable silent data corruption (SDC)\n\t\t\t\t  attacks.", "In the case of confidential compute technologies where system firmware\n\t\t\t\t  is not a trusted component, error handling controls can be\n\t\t\t\t  misconfigured to trigger this weakness and attack the assets protected\n\t\t\t\t  by confidential compute."], "#text_blocks": ["For system security, if an uncorrectable error occurs but is not\n\t\t\t\t  reported to the execution core and handled before the core attempts to\n\t\t\t\t  consume the data that is read/written through the corrupted\n\t\t\t\t  transactions, then this could enable silent data corruption (SDC)\n\t\t\t\t  attacks.", "In the case of confidential compute technologies where system firmware\n\t\t\t\t  is not a trusted component, error handling controls can be\n\t\t\t\t  misconfigured to trigger this weakness and attack the assets protected\n\t\t\t\t  by confidential compute."]}}]}, "Observed_Examples": {"Observed_Example": {"Reference": "[REF-1468]", "Description": "Open source silicon root of trust (RoT) product does not immediately report when an integrity check fails for memory requests, causing the product to accept and continue processing data [REF-1468]", "Link": "https://github.com/lowRISC/opentitan/issues/11336"}}, "References": {"Reference": {"@External_Reference_ID": "REF-1468"}}, "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": "Amisha Srivastava", "Submission_Organization": "University of Texas at Dallas", "Submission_Date": "2023-12-20", "Submission_Version": "4.17", "Submission_ReleaseDate": "2025-04-03"}, "Modification": [{"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2025-12-11", "Modification_Version": "4.19", "Modification_ReleaseDate": "2025-12-11", "Modification_Comment": "updated Demonstrative_Examples, Weakness_Ordinalities"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2026-10-28", "Modification_Version": "5.0", "Modification_ReleaseDate": "2026-10-28", "Modification_Comment": "updated Demonstrative_Examples, Detection_Factors"}], "Contribution": {"@Type": "Content", "Contribution_Name": "Hareesh Khattri", "Contribution_Organization": "Intel Corporation", "Contribution_Date": "2025-03-25", "Contribution_Version": "4.17", "Contribution_ReleaseDate": "2025-04-03", "Contribution_Comment": "Contributed an observed example and a demonstrative example."}}, "entry_type": "Weakness"}