{"@ID": "1422", "@Name": "Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution", "@Abstraction": "Base", "@Structure": "Simple", "@Status": "Incomplete", "Description": "A processor event or prediction may allow incorrect or stale data to\n\t\t  be forwarded to transient operations, potentially exposing data over a\n\t\t  covert channel.", "Extended_Description": {"xhtml:p": ["Software may use a variety of techniques to preserve the\n\t\t\tconfidentiality of private data that is accessible within the current\n\t\t\tprocessor context. For example, the memory safety and type safety\n\t\t\tproperties of some high-level programming languages help to prevent\n\t\t\tsoftware written in those languages from exposing private data. As a\n\t\t\tsecond example, software sandboxes may co-locate multiple users'\n\t\t\tsoftware within a single process. The processor's Instruction Set\n\t\t\tArchitecture (ISA) may permit one user's software to access another\n\t\t\tuser's data (because the software shares the same address space), but\n\t\t\tthe sandbox prevents these accesses by using software techniques such\n\t\t\tas bounds checking.", "If incorrect or stale data can be forwarded (for example, from a\n\t\t\tcache) to transient operations, then the operations'\n\t\t\tmicroarchitectural side effects may correspond to the data. If an\n\t\t\tattacker can trigger these transient operations and observe their side\n\t\t\teffects through a covert channel, then the attacker may be able to\n\t\t\tinfer the data. For example, an attacker process may induce transient\n\t\t\texecution in a victim process that causes the victim to inadvertently\n\t\t\taccess and then expose its private data via a covert channel. In the\n\t\t\tsoftware sandbox example, an attacker sandbox may induce transient\n\t\t\texecution in its own code, allowing it to transiently access and\n\t\t\texpose data in a victim sandbox that shares the same address space.", "Consequently, weaknesses that arise from incorrect/stale data\n\t\t\tforwarding might violate users' expectations of software-based memory\n\t\t\tsafety and isolation techniques. If the data forwarding behavior is\n\t\t\tnot properly documented by the hardware vendor, this might violate the\n\t\t\tsoftware vendor's expectation of how the hardware should behave."]}, "Related_Weaknesses": {"Related_Weakness": [{"@Nature": "ChildOf", "@CWE_ID": "1420", "@View_ID": "1000", "@Ordinal": "Primary"}, {"@Nature": "ChildOf", "@CWE_ID": "1420", "@View_ID": "1194", "@Ordinal": "Primary"}]}, "Weakness_Ordinalities": {"Weakness_Ordinality": {"Ordinality": "Primary"}}, "Applicable_Platforms": {"Language": {"@Class": "Not Language-Specific", "@Prevalence": "Undetermined"}, "Operating_System": {"@Class": "Not OS-Specific", "@Prevalence": "Undetermined"}, "Architecture": {"@Class": "Not Architecture-Specific", "@Prevalence": "Undetermined"}, "Technology": {"@Class": "Not Technology-Specific", "@Prevalence": "Undetermined"}}, "Modes_Of_Introduction": {"Introduction": {"Phase": "Architecture and Design", "Note": {"xhtml:p": "This weakness can be introduced by data speculation techniques,\n\t\t\t\tor when the processor pipeline is designed to check exception\n\t\t\t\tconditions concurrently with other operations. This weakness can also\n\t\t\t\tpersist after a CWE-1421 weakness has been mitigated. For example,\n\t\t\t\tsuppose that a processor can forward stale data from a shared\n\t\t\t\tmicroarchitectural buffer to dependent transient operations, and\n\t\t\t\tfurthermore suppose that the processor has been patched to flush the\n\t\t\t\tbuffer on context switches. This mitigates the CWE-1421 weakness, but the\n\t\t\t\tstale-data forwarding behavior may persist as a CWE-1422 weakness unless\n\t\t\t\tthis behavior is also patched."}}}, "Common_Consequences": {"Consequence": {"Scope": "Confidentiality", "Impact": "Read Memory", "Likelihood": "Medium"}}, "Detection_Methods": {"Detection_Method": [{"Method": "Automated Static Analysis", "Description": {"xhtml:p": "A variety of automated static analysis tools can identify\n\t\t\t\tpotentially exploitable code sequences in software. These tools may\n\t\t\t\tperform the analysis on source code, on binary code, or on an\n\t\t\t\tintermediate code representation (for example, during compilation)."}, "Effectiveness": "Moderate", "Effectiveness_Notes": "Automated static analysis may not reveal all weaknesses in a processor\n\t\t\t\tspecification and should be combined with other detection methods to improve coverage."}, {"Method": "Manual Analysis", "Description": {"xhtml:p": "This weakness can be detected in hardware by manually\n\t\t\t\tinspecting processor specifications. Features that exhibit this\n\t\t\t\tweakness may include microarchitectural predictors, access control\n\t\t\t\tchecks that occur out-of-order, or any other features that can allow\n\t\t\t\toperations to execute without committing to architectural state.Hardware designers can also scrutinize aspects\n\t\t\t\tof the instruction set architecture that have undefined\n\t\t\t\tbehavior; these can become a focal point\n\t\t\t\twhen applying other detection methods."}, "Effectiveness": "Moderate", "Effectiveness_Notes": "Manual analysis may not reveal all weaknesses in a processor specification\n\t\t\t\tand should be combined with other detection methods to improve coverage."}, {"Method": "Automated Analysis", "Description": {"xhtml:p": ["Software vendors can release tools that detect presence of known\n\t\t\t\tweaknesses on a processor. For example, some of these tools can\n\t\t\t\tattempt to transiently execute a vulnerable code sequence and detect\n\t\t\t\twhether code successfully leaks data in a manner consistent with the\n\t\t\t\tweakness under test. Alternatively, some hardware vendors provide\n\t\t\t\tenumeration for the presence of a weakness (or lack of a\n\t\t\t\tweakness). These enumeration bits can be checked and reported by\n\t\t\t\tsystem software. For example, Linux supports these checks for many\n\t\t\t\tcommodity processors:", "$ cat /proc/cpuinfo | grep bugs | head -n 1", "bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed"]}, "Effectiveness": "High", "Effectiveness_Notes": "This method can be useful for detecting whether a processor if affected by known weaknesses, but it may not be useful for detecting unknown weaknesses."}]}, "Potential_Mitigations": {"Mitigation": [{"Phase": "Architecture and Design", "Description": {"xhtml:p": "The hardware designer can attempt to prevent transient\n\t\t\t\texecution from causing observable discrepancies in specific covert\n\t\t\t\tchannels."}, "Effectiveness": "Limited", "Effectiveness_Notes": "Instructions or features that constrain transient execution or suppress its side effects may impact performance."}, {"Phase": "Requirements", "Description": {"xhtml:p": "Processor designers, system software vendors, or other\n\t\t\t\tagents may choose to restrict the ability of unprivileged software to\n\t\t\t\taccess to high-resolution timers that are commonly used to monitor\n\t\t\t\tcovert channels."}, "Effectiveness": "Defense in Depth", "Effectiveness_Notes": "Disabling specific predictors or other hardware features may result in significant performance overhead."}, {"Phase": "Requirements", "Description": {"xhtml:p": "Processor designers may expose instructions or other\n\t\t\t\tarchitectural features that allow software to mitigate the effects of\n\t\t\t\ttransient execution, but without disabling predictors. These features\n\t\t\t\tmay also help to limit opportunities for data exposure."}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "Instructions or features that constrain transient\n\t\t\t\texecution or suppress its side effects may impact performance."}}, {"Phase": "Requirements", "Description": {"xhtml:p": "Processor designers may expose registers (for example,\n\t\t\t\tcontrol registers or model-specific registers) that allow privileged\n\t\t\t\tand/or user software to disable specific predictors or other hardware\n\t\t\t\tfeatures that can cause confidential data to be exposed during\n\t\t\t\ttransient execution."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "Disabling specific predictors or other hardware\n\t\t\t\tfeatures may result in significant performance overhead."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "Use software techniques (including the use of\n\t\t\t\tserialization instructions) that are intended to reduce the number of\n\t\t\t\tinstructions that can be executed transiently after a processor event\n\t\t\t\tor misprediction."}, "Effectiveness": "Incidental", "Effectiveness_Notes": {"xhtml:p": "Some transient execution weaknesses can be\n\t\t\t\texploited even if a single instruction is executed transiently after a\n\t\t\t\tprocessor event or mis-prediction. This mitigation strategy has many\n\t\t\t\tother pitfalls that prevent it from eliminating this weakness\n\t\t\t\tentirely. For example, see [REF-1389]."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "Isolate sandboxes or managed runtimes in separate address\n\t\t\t\tspaces (separate processes)."}, "Effectiveness": "High", "Effectiveness_Notes": {"xhtml:p": "Process isolation is also an effective strategy\n\t\t\t\tto mitigate many other kinds of weaknesses."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "Include serialization instructions (for example, LFENCE)\n\t\t\t\tthat prevent processor events or mis-predictions prior to the\n\t\t\t\tserialization instruction from causing transient execution after the\n\t\t\t\tserialization instruction. For some weaknesses, a serialization\n\t\t\t\tinstruction can also prevent a processor event or a mis-prediction\n\t\t\t\tfrom occurring after the serialization instruction (for example,\n\t\t\t\tCVE-2018-3639 can allow a processor to predict that a load will not\n\t\t\t\tdepend on an older store; a serialization instruction between the\n\t\t\t\tstore and the load may allow the store to update memory and prevent\n\t\t\t\tthe mis-prediction from happening at all)."}, "Effectiveness": "Moderate", "Effectiveness_Notes": {"xhtml:p": "When used to comprehensively mitigate a transient\n\t\t\t\texecution weakness, serialization instructions can introduce\n\t\t\t\tsignificant performance overhead."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "Use software techniques that can mitigate the\n\t\t\t\tconsequences of transient execution. For example, address masking can\n\t\t\t\tbe used in some circumstances to prevent out-of-bounds transient\n\t\t\t\treads."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "Address masking and related software mitigation\n\t\t\t\ttechniques have been used to harden specific code sequences that could\n\t\t\t\tpotentially be exploited via transient execution. For example, the\n\t\t\t\tLinux kernel makes limited use of this technique to mitigate\n\t\t\t\tbounds-check bypass [REF-1390]."}}, {"Phase": "Build and Compilation", "Description": {"xhtml:p": "If the weakness is exposed by a single instruction (or a\n\t\t\t\tsmall set of instructions), then the compiler (or JIT, etc.) can be\n\t\t\t\tconfigured to prevent the affected instruction(s) from being\n\t\t\t\tgenerated, and instead generate an alternate sequence of instructions\n\t\t\t\tthat is not affected by the weakness."}, "Effectiveness": "Limited", "Effectiveness_Notes": {"xhtml:p": "This technique is only effective for software\n\t\t\t\tthat is compiled with this mitigation."}}, {"Phase": "Documentation", "Description": {"xhtml:p": "If a hardware feature can allow incorrect or stale data\n\t\t\t\tto be forwarded to transient operations, the hardware designer may opt\n\t\t\t\tto disclose this behavior in architecture documentation. This\n\t\t\t\tdocumentation can inform users about potential consequences and\n\t\t\t\teffective mitigations."}, "Effectiveness": "High"}]}, "Demonstrative_Examples": {"Demonstrative_Example": [{"Intro_Text": {"xhtml:p": "Faulting loads in a victim domain may trigger incorrect transient\n\t\t\t\tforwarding, which leaves secret-dependent traces in the\n\t\t\t\tmicroarchitectural state. Consider this code sequence example from\n\t\t\t\t[REF-1391]."}, "Example_Code": {"@Nature": "Bad", "@Language": "C", "xhtml:br": [null, null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": [null, null], "#text": "*arg_copy = untrusted_arg;\n\t\t\t\t\tarray[**trusted_ptr * 4096];"}, "#text": "void call_victim(size_t untrusted_arg) {\n\t\t\t\t  \n\t\t\t\t  }"}, "Body_Text": {"xhtml:p": ["A processor with this weakness will store the value of untrusted_arg\n\t\t\t\t(which may be provided by an attacker) to the stack, which is trusted\n\t\t\t\tmemory. Additionally, this store operation will save this value in\n\t\t\t\tsome microarchitectural buffer, for example, the store buffer.", "In this code sequence, trusted_ptr is dereferenced while the attacker\n\t\t\t\tforces a page fault. The faulting load causes the processor to\n\t\t\t\tmis-speculate by forwarding untrusted_arg as the (transient) load\n\t\t\t\tresult. The processor then uses untrusted_arg for the pointer\n\t\t\t\tdereference. After the fault has been handled and the load has been\n\t\t\t\tre-issued with the correct argument, secret-dependent information\n\t\t\t\tstored at the address of trusted_ptr remains in microarchitectural\n\t\t\t\tstate and can be extracted by an attacker using a vulnerable code\n\t\t\t\tsequence."]}}, {"Intro_Text": {"xhtml:p": "Some processors try to predict when a store will forward data to a\n\t\t\t\tsubsequent load, even when the address of the store or the load is not\n\t\t\t\tyet known. For example, on Intel processors this feature is called a\n\t\t\t\tFast Store Forwarding Predictor [REF-1392], and on AMD processors the\n\t\t\t\tfeature is called Predictive Store Forwarding [REF-1393]. A\n\t\t\t\tmisprediction can cause incorrect or stale data to be forwarded from a\n\t\t\t\tstore to a load, as illustrated in the following code snippet from\n\t\t\t\t[REF-1393]:"}, "Example_Code": {"@Nature": "Bad", "@Language": "C", "xhtml:br": [null, null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": [null, null, null], "#text": "unsigned char v;\n\t\t\t\t\tidx_array[0] = 4096;\n\t\t\t\t\tv = array[idx_array[idx] * (idx)];"}, "#text": "void fn(int idx) {\n\t\t\t\t  \n\t\t\t\t  }"}, "Body_Text": {"xhtml:p": ["In this example, assume that the parameter idx can only be 0 or 1, and\n\t\t\t\tassume that idx_array initially contains all 0s. Observe that the\n\t\t\t\tassignment to v in line 4 will be array[0], regardless of whether\n\t\t\t\tidx=0 or idx=1. Now suppose that an attacker repeatedly invokes fn\n\t\t\t\twith idx=0 to train the store forwarding predictor to predict that the\n\t\t\t\tstore in line 3 will forward the data 4096 to the load idx_array[idx]\n\t\t\t\tin line 4. Then, when the attacker invokes fn with idx=1 the predictor\n\t\t\t\tmay cause idx_array[idx] to transiently produce the incorrect value\n\t\t\t\t4096, and therefore v will transiently be assigned the value\n\t\t\t\tarray[4096], which otherwise would not have been accessible in line 4.", "Although this toy example is benign (it doesn't transmit array[4096]\n\t\t\t\tover a covert channel), an attacker may be able to use similar\n\t\t\t\ttechniques to craft and train malicious code sequences to, for\n\t\t\t\texample, read data beyond a software sandbox boundary."]}}]}, "Observed_Examples": {"Observed_Example": [{"Reference": "CVE-2020-0551", "Description": "A fault, microcode assist, or abort may allow transient\n\t\t\t\tload operations to forward malicious stale data to dependent\n\t\t\t\toperations executed by a victim, causing the victim to unintentionally\n\t\t\t\taccess and potentially expose its own data over a covert channel.", "Link": "https://www.cve.org/CVERecord?id=CVE-2020-0551"}, {"Reference": "CVE-2020-8698", "Description": "A fast store forwarding predictor may allow store\n\t\t\t\toperations to forward incorrect data to transient load operations,\n\t\t\t\tpotentially exposing data over a covert channel.", "Link": "https://www.cve.org/CVERecord?id=CVE-2020-8698"}]}, "References": {"Reference": [{"@External_Reference_ID": "REF-1389"}, {"@External_Reference_ID": "REF-1390"}, {"@External_Reference_ID": "REF-1391"}, {"@External_Reference_ID": "REF-1392"}, {"@External_Reference_ID": "REF-1393"}]}, "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": {"xhtml:p": "If a weakness arises from forwarding of\n\t\t\t  incorrect/stale data that is not accessible within the current\n\t\t\t  processor context, then CWE-1421 may be more appropriate for\n\t\t\t  the mapping task.", "#text": "Use only when the weakness arises from forwarding of\n\t\t\t  incorrect/stale data, and the data is not architecturally\n\t\t\t  restricted (that is, the forwarded data is accessible within the current processor context)."}, "Reasons": {"Reason": {"@Type": "Acceptable-Use"}}}, "Content_History": {"Submission": {"Submission_Name": "Scott D. Constable", "Submission_Organization": "Intel Corporation", "Submission_Date": "2023-09-19", "Submission_Version": "4.14", "Submission_ReleaseDate": "2024-02-29"}, "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 Weakness_Ordinalities"}, "Contribution": [{"@Type": "Content", "Contribution_Name": "David Kaplan", "Contribution_Organization": "AMD", "Contribution_Date": "2024-01-22", "Contribution_Version": "4.14", "Contribution_ReleaseDate": "2024-02-29", "Contribution_Comment": "Member of Microarchitectural Weaknesses Working Group"}, {"@Type": "Content", "Contribution_Name": "Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett", "Contribution_Organization": "Arm", "Contribution_Date": "2024-01-22", "Contribution_Version": "4.14", "Contribution_ReleaseDate": "2024-02-29", "Contribution_Comment": "Members of Microarchitectural Weaknesses Working Group"}, {"@Type": "Content", "Contribution_Name": "Jason Oberg", "Contribution_Organization": "Cycuity", "Contribution_Date": "2024-01-22", "Contribution_Version": "4.14", "Contribution_ReleaseDate": "2024-02-29", "Contribution_Comment": "Member of Microarchitectural Weaknesses Working Group"}, {"@Type": "Content", "Contribution_Name": "Priya B. Iyer", "Contribution_Organization": "Intel Corporation", "Contribution_Date": "2024-01-22", "Contribution_Version": "4.14", "Contribution_ReleaseDate": "2024-02-29", "Contribution_Comment": "Member of Microarchitectural Weaknesses Working Group"}, {"@Type": "Content", "Contribution_Name": "Nicole Fern", "Contribution_Organization": "Riscure", "Contribution_Date": "2024-01-22", "Contribution_Version": "4.14", "Contribution_ReleaseDate": "2024-02-29", "Contribution_Comment": "Member of Microarchitectural Weaknesses Working Group"}]}}