|Industry-wide severity ratings can be found in the National Vulnerability Database
An in-domain transient execution attack methodology known as Speculative Code Store Bypass (SCSB) may allow data values to be inferred during the transient execution of self-modifying code (SMC) on some Intel processors. SCSB has been assigned CVE-2021-0089 with a base score of CVSS 6.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N. Refer to the Affected Processors table for a list of processors affected by SCSB.
A software SMC environment such as a just-in-time (JIT) compiler may generate or modify instruction bytes, and then execute those bytes without serialization. Code bytes may be fetched and executed transiently by the processor before the processor observes a recent store to those code bytes. When an older store is observed, the pipeline will be cleared and instructions re-fetched. In some contexts, an adversary may be able to control the stale code bytes executed transiently. This may allow the adversary to cause specific data to be inferable via a microarchitectural covert channel. Incidental channels (for example, CPU cache state) can be used to encode and transmit data that is accessed transiently; when an incidental channel is used by an adversary to intentionally transmit data, it is often referred to as a covert channel.
Software environments that use SMC may be impacted by SCSB. Note that the adversary must be able to generate and execute SMC within the same address space where the targeted victim data is located (thus, SCSB is in-domain1). For example, some JIT compilers inside web browsers may satisfy these requirements, and therefore may be impacted by SCSB.
In common with other in-domain transient execution attacks, process isolation is an effective mitigation for SCSB. More information on using process isolation for in-domain transient execution attack mitigations can be found in Managed Runtime Speculative Execution Side Channel Mitigations.
Alternatively, serialization can be employed between writing the code bytes and executing the code bytes to help ensure that the old code bytes are not transiently executed:
- Architectural serialization operations (for example, CPUID or INVLPG) will help ensure that the code modification is synchronized.
- On current and in-development processors, LFENCE, SYSRET, or INVPCID will help ensure that the old code bytes are not transiently executed but they may not satisfy the synchronization guidelines2 described in the Intel Software Developer's Manual (SDM).
Some software SMC environments enforce an “either writable or executable” policy on pages with modifiable code. This is sometimes written as “W^X” policy. The system calls to transition a user page from writable to executable already include the serialization necessary to mitigate SCSB. For example, if a software SMC environment does not use process isolation but does enforce a W^X policy with serialization across W/X transitions, then the environment should not be impacted by SCSB.
The Intel Software Developer's Manual documents several options for implementing functional self-modifying code but does not address what can occur during transient execution. Software that needs to prevent transient execution of stale bytes should follow the additional guidance in this document.
- Refer to Refined Speculative Execution Terminology.
- This is Option 2 in the Self-Modifying Code section 8.1.3 in volume 3A of the Intel® 64 and IA-32 Architectures Software Developer’s Manuals.