A processor event may allow transient operations to access
architecturally restricted data (for example, in another address
space) in a shared microarchitectural structure (for example, a CPU
cache), potentially exposing the data over a covert channel.

Many commodity processors have Instruction Set Architecture (ISA)
features that protect software components from one another. These
features can include memory segmentation, virtual memory, privilege
rings, trusted execution environments, and virtual machines, among
others. For example, virtual memory provides each process with its own
address space, which prevents processes from accessing each other's
private data. Many of these features can be used to form
hardware-enforced security boundaries between software components.
Many commodity processors also share microarchitectural resources that
cache (temporarily store) data, which may be confidential. These
resources may be shared across processor contexts, including across
SMT threads, privilege rings, or others.
When transient operations allow access to ISA-protected data in a
shared microarchitectural resource, this might violate users'
expectations of the ISA feature that is bypassed. For example, if
transient operations can access a victim's private data in a shared
microarchitectural resource, then the operations' microarchitectural
side effects may correspond to the accessed data. If an attacker can
trigger these transient operations and observe their side effects
through a covert channel [REF-1400], then the attacker may be able to infer the
victim's private data. Private data could include sensitive program
data, OS/VMM data, page table data (such as memory addresses), system
configuration data (see Demonstrative Example 3), or any other data
that the attacker does not have the required privileges to access.

Primary

Architecture and Design
This weakness can be introduced during hardware architecture and
design if a data path allows architecturally restricted data to
propagate to operations that execute before an older mis-prediction or
processor event (such as an exception) is caught.

Implementation
This weakness can be introduced during system software
implementation if state-sanitizing operations are not invoked when
switching from one context to another, according to the hardware
vendor's recommendations for mitigating the weakness.

System Configuration
This weakness can be introduced if the system has not been
configured according to the hardware vendor's recommendations for
mitigating the weakness.

Architecture and Design
This weakness can be introduced when an access control check
(for example, checking page permissions) can proceed in parallel with
the access operation (for example, a load) that is being checked. If
the processor can allow the access operation to execute before the
check completes, this race condition may allow subsequent transient
operations to expose sensitive information.

Confidentiality
Read Memory
Medium
<<put the information here>>

Manual Analysis
This weakness can be detected in hardware by
manually inspecting processor specifications. Features that exhibit
this weakness may include microarchitectural predictors, access
control checks that occur out-of-order, or any other features that can
allow operations to execute without committing to architectural
state. Academic researchers have demonstrated that new hardware
weaknesses can be discovered by examining publicly available patent
filings, for example [REF-1405] and [REF-1406]. Hardware designers can also scrutinize aspects of the instruction set
architecture that have undefined behavior; these can become a focal point when applying other
detection methods.

Moderate
Manual analysis may not reveal all
weaknesses in a processor specification
and should be combined with other detection methods
to improve coverage.

Automated Analysis
This weakness can be detected (pre-discovery) in hardware by
employing static or dynamic taint analysis methods [REF-1401]. These
methods can label data in one context (for example, kernel data) and
perform information flow analysis (or a simulation, etc.) to determine
whether tainted data can appear in another context (for example, user
mode). Alternatively, stale or invalid data in shared
microarchitectural resources can be marked as tainted, and the taint
analysis framework can identify when transient operations encounter
tainted data.

Moderate
Automated static or dynamic taint
analysis may not reveal all weaknesses in a processor
specification and should be combined with other detection
methods to improve coverage.

Automated Analysis
Software vendors can release tools that detect
presence of known weaknesses (post-discovery) on a processor. For example, some of
these tools can attempt to transiently execute a vulnerable code
sequence and detect whether code successfully leaks data in a manner
consistent with the weakness under test. Alternatively, some hardware
vendors provide enumeration for the presence of a weakness (or lack of
a weakness). These enumeration bits can be checked and reported by
system software. For example, Linux supports these checks for many
commodity 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

High
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.

Fuzzing
Academic researchers have demonstrated that this
weakness can be detected in hardware using software fuzzing
tools that treat the underlying hardware as a black box
([REF-1406], [REF-1430])

Opportunistic
Fuzzing may not reveal all weaknesses
in a processor specification and should be combined with
other detection methods to improve coverage.

Architecture and Design
Hardware designers may choose to engineer the processor's
pipeline to prevent architecturally restricted data from being used by
operations that can execute transiently.

High

Architecture and Design
Hardware designers may choose not to share
microarchitectural resources that can contain sensitive data, such as
fill buffers and store buffers.

Moderate
This can be highly effective at preventing this
weakness from being exposed across different SMT threads or different
processor cores. It is generally less practical to isolate these
resources between different contexts (for example, user and kernel)
that may execute on the same SMT thread or processor core.

Architecture and Design
Hardware designers may choose to sanitize specific
microarchitectural state (for example, store buffers) when the
processor transitions to a different context, such as whenever a
system call is invoked. Alternatively, the hardware may expose
instruction(s) that allow software to sanitize microarchitectural
state according to the user or system administrator's threat
model. These mitigation approaches are similar to those that address
CWE-226; however, sanitizing microarchitectural state may not be the
optimal or best way to mitigate this weakness on every processor
design.

Moderate
Sanitizing shared state on context transitions
may not be practical for all processors, especially when the amount of
shared state affected by the weakness is relatively
large. Additionally, this technique may not be practical unless there
is a synchronous transition between two processor contexts that would
allow the affected resource to be sanitized. For example, this
technique alone may not suffice to mitigate asynchronous access to a
resource that is shared by two SMT threads.

Architecture and Design
The hardware designer can attempt to prevent transient
execution from causing observable discrepancies in specific covert
channels.

Limited
This technique has many pitfalls. For example,
InvisiSpec was an early attempt to mitigate this weakness by blocking
"micro-architectural covert and side channels through the
multiprocessor data cache hierarchy due to speculative loads" [REF-1417].
Commodity processors and SoCs have many covert and side channels that
exist outside of the data cache hierarchy. Even when some of these
channels are blocked, others (such as execution ports [REF-1418]) may
allow an attacker to infer confidential data. Mitigation strategies
that attempt to prevent transient execution from causing observable
discrepancies also have other pitfalls, for example, see [REF-1419].

Architecture and Design
Software architects may design software to enforce strong
isolation between different contexts. For example, kernel page table
isolation (KPTI) mitigates the Meltdown vulnerability [REF-1401] by
separating user-mode page tables from kernel-mode page tables, which
prevents user-mode processes from using Meltdown to transiently access
kernel memory [REF-1404].

Limited
Isolating different contexts across a process
boundary (or another kind of architectural boundary) may only be
effective for some weaknesses.

Build and Compilation
If the weakness is exposed by a single instruction (or a
small set of instructions), then the compiler (or JIT, etc.) can be
configured to prevent the affected instruction(s) from being
generated, and instead generate an alternate sequence of instructions
that is not affected by the weakness.

Limited
This technique may only be fully effective if it
is applied to all software that runs on the system. Also, relatively
few observed examples of this weakness have exposed data through only
a single instruction.

Build and Compilation
Use software techniques (including the use of
serialization instructions) that are intended to reduce the number of
instructions that can be executed transiently after a processor event
or misprediction.

Incidental
Some transient execution weaknesses can be
exploited even if a single instruction is executed transiently after a
processor event or mis-prediction. This mitigation strategy has many
other pitfalls that prevent it from eliminating this weakness
entirely. For example, see [REF-1389].

Implementation
System software can mitigate this weakness by invoking
state-sanitizing operations when switching from one context to
another, according to the hardware vendor's recommendations.

Limited
This technique may not be able to mitigate
weaknesses that arise from resource sharing across SMT threads.

System Configuration
Some systems may allow the user to disable (for example,
in the BIOS) sharing of the affected resource.

Limited
Disabling resource sharing (for example, by
disabling SMT) may result in significant performance overhead.

System Configuration
Some systems may allow the user to disable (for example,
in the BIOS) microarchitectural features that allow transient access
to architecturally restricted data.

Limited
Disabling microarchitectural features such as
predictors may result in significant performance overhead.

Patching and Maintenance
The hardware vendor may provide a patch to sanitize the
affected shared microarchitectural state when the processor
transitions to a different context.

Moderate
This technique may not be able to mitigate
weaknesses that arise from resource sharing across SMT threads.

Patching and Maintenance
This kind of patch may not be feasible or
implementable for all processors or all weaknesses.

Limited

Requirements
Processor designers, system software vendors, or other
agents may choose to restrict the ability of unprivileged software to
access to high-resolution timers that are commonly used to monitor
covert channels.

Defense in Depth
Specific software algorithms can be used by an attacker to compensate for a lack of a high-resolution time source [REF-1420].

Some processors may perform access control checks in parallel with
memory read/write operations. For example, when a user-mode program
attempts to read data from memory, the processor may also need to
check whether the memory address is mapped into user space or kernel
space. If the processor performs the access concurrently with the
check, then the access may be able to transiently read kernel data
before the check completes. This race condition is demonstrated in the
following code snippet from [REF-1408], with additional annotations:

1 ; rcx = kernel address, rbx = probe array
2 xor rax, rax # set rax to 0
3 retry:
4 mov al, byte [rcx] # attempt to read kernel memory
5 shl rax, 0xc # multiply result by page size (4KB)
6 jz retry # if the result is zero, try again
7 mov rbx, qword [rbx + rax] # transmit result over a cache covert channel

Vulnerable processors may return kernel data from a shared
microarchitectural resource in line 4, for example, from the
processor's L1 data cache. Since this vulnerability involves a race
condition, the mov in line 4 may not always return kernel data (that
is, whenever the check "wins" the race), in which case this
demonstration code re-attempts the access in line 6. The accessed data
is multiplied by 4KB, a common page size, to make it easier to observe
via a cache covert channel after the transmission in line 7. The use
of cache covert channels to observe the side effects of transient
execution has been described in [REF-1408].

Many commodity processors share microarchitectural fill buffers
between sibling hardware threads on simultaneous multithreaded (SMT)
processors. Fill buffers can serve as temporary storage for data that
passes to and from the processor's caches. Microarchitectural Fill
Buffer Data Sampling (MFBDS) is a vulnerability that can allow a
hardware thread to access its sibling's private data in a shared fill
buffer. The access may be prohibited by the processor's ISA, but MFBDS
can allow the access to occur during transient execution, in
particular during a faulting operation or an operation that triggers a
microcode assist.

More information on MFBDS can be found in [REF-1405] and [REF-1409].

Some processors may allow access to system registers (for example,
system coprocessor registers or model-specific registers) during
transient execution. This scenario is depicted in the code snippet
below. Under ordinary operating circumstances, code in exception level
0 (EL0) is not permitted to access registers that are restricted to
EL1, such as TTBR0_EL1. However, on some processors an earlier
mis-prediction can cause the MRS instruction to transiently read the
value in an EL1 register. In this example, a conditional branch (line
2) can be mis-predicted as "not taken" while waiting for a slow load
(line 1). This allows MRS (line 3) to transiently read the value in
the TTBR0_EL1 register. The subsequent memory access (line 6) can
allow the restricted register's value to become observable, for
example, over a cache covert channel.

Code snippet is from [REF-1410]. See also [REF-1411].

1 LDR X1, [X2] ; arranged to miss in the cache
2 CBZ X1, over ; This will be taken
3 MRS X3, TTBR0_EL1;
4 LSL X3, X3, #imm
5 AND X3, X3, #0xFC0
6 LDR X5, [X6,X3] ; X6 is an EL0 base address
7 over

CVE-2017-5715
A fault may allow transient user-mode operations to
access kernel data cached in the L1D, potentially exposing the data
over a covert channel.

https://www.cve.org/CVERecord?id=CVE-2017-5715

CVE-2018-3615
A fault may allow transient non-enclave operations to
access SGX enclave data cached in the L1D, potentially exposing the
data over a covert channel.

https://www.cve.org/CVERecord?id=CVE-2018-3615

CVE-2019-1135
A TSX Asynchronous Abort may allow transient operations
to access architecturally restricted data, potentially exposing the
data over a covert channel.

https://www.cve.org/CVERecord?id=CVE-2019-1135

Allowed
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
If a weakness can potentially be exploited to
infer data that is accessible inside or outside the current
processor context, then the weakness could map to CWE-1421 and
to another CWE such as CWE-1420.

Scott D. Constable
Intel Corporation
2023-09-19
4.14
2024-02-29

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated References, Relationships

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated References, Weakness_Ordinalities

David Kaplan
AMD
2024-01-22
4.14
2024-02-29
Member of Microarchitectural Weaknesses Working Group

Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett
Arm
2024-01-22
4.14
2024-02-29
Members of Microarchitectural Weaknesses Working Group

Jason Oberg
Cycuity
2024-01-22
4.14
2024-02-29
Member of Microarchitectural Weaknesses Working Group

Priya B. Iyer
Intel Corporation
2024-01-22
4.14
2024-02-29
Member of Microarchitectural Weaknesses Working Group

Nicole Fern
Riscure
2024-01-22
4.14
2024-02-29
Member of Microarchitectural Weaknesses Working Group