Full Report
The rep movsb instruction is a super common way to move around memory in x86. The destination, direction and amount are all set in this call, but the processor does stuff under the hood. In x86, the instruction decoding is very relaxed. Sometimes, compilers use redundant prefixes to pad a single instruction to get a nice alignment boundary. There are several prefixes that can be used, such as rex, vex and evex. On i386, there are only 4 registers which were encoded in the instruction. When this was doubled to 8 registers, there was no where to go. So, the rex instruction adds an additional byte to the beginning of the instruction to encode this information. If this is found before an instruction like movsb, then it's silently ignored. Well, in most cases. The fast short repeat move instruction; the feature is all about moving small (less than 128 bytes) strings quickly To test for architecture level issues, the author of this post uses Oracle Serialization. This generates two programs but transforms it to include micro architecture changes like fencing instructions. If the state of the program after serializing it is different, then something weird has happened. While fuzzing using this technique, they noticed that adding redundant rex.r prefix instructions to an FSRM optimized operation caused unpredictable results. For instance, branches to random locations, branches being ignored and many other weird things. Somehow, this had corrupted the state. Within a few days, they found out that triggering this on multiple cores led to exceptions and halts. Within an unprivileged guest VM, this could be used to crash the computer! So, what's going on? The CPU has two main components: frontend and backend. The frontend fetches, decoding and generates the ops for the backend to execute. The backend then executes these instructions. The authors of the post think that there is a miscalculation in the movsb instruction size, which leads to extra backend entries to be processed. Is this exploitable? Probably! However, there is no insight into what's being processed under the hood. So, the information above is just a guess from the author. Awesome post once again!
Analysis Summary
# Vulnerability: Reptar (CPU Microarchitectural State Corruption)
## CVE Details
- **CVE ID:** CVE-2023-23583
- **CVSS Score:** 8.8 (High)
- **CWE:** CWE-754: Improper Check for Unusual or Exceptional Conditions
## Affected Systems
- **Products:** Intel CPUs supporting Fast Short Repeat Move (FSRM).
- **Versions:** Includes but is not limited to:
- Ice Lake
- Rocket Lake
- Tiger Lake
- Alder Lake
- Raptor Lake
- Sapphire Rapids
- **Configurations:** Systems where the FSRM feature is enabled (visible via `fsrm` flag in `/proc/cpuinfo`).
## Vulnerability Description
Reptar is a microarchitectural flaw involving the handling of redundant prefixes—specifically the `REX` prefix—when applied to the `REP MOVSB` instruction on processors supporting Fast Short Repeat Move (FSRM).
While `REX` prefixes are typically ignored for instructions with implicit operands like `MOVSB`, the FSRM optimization logic miscalculates the instruction size or state when redundant prefixes are present. This leads to a "glitch state" where the CPU's frontend and backend become desynchronized. The frontend may generate more micro-operations (uops) than the Reorder Buffer (ROB) expects, leading to corruption of the architectural state, incorrect instruction pointer calculations, and interference between SMT threads.
## Exploitation
- **Status:** PoC available (discovered by Google researchers).
- **Complexity:** Low (requires execution of a specific unprivileged instruction sequence).
- **Attack Vector:** Local (can be triggered by a guest VM or unprivileged user).
## Impact
- **Confidentiality:** Potential (While not confirmed, researchers suspect cross-thread interference could lead to data leakage).
- **Integrity:** High (Can cause unpredictable execution, branches to random locations, or ignored instructions).
- **Availability:** High (Triggering the flaw on multiple cores simultaneously leads to a Machine Check Exception [MCE] and system halt/reboot).
## Remediation
### Patches
- **Microcode Updates:** Intel has released updated microcode via [INTEL-SA-00950](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00950.html). Users should apply BIOS/UEFI updates from their OEM or OS-level microcode patches (e.g., `intel-microcode` on Linux).
### Workarounds
- **Disable Fast Strings:** The flaw can be mitigated by disabling the fast strings feature via the `IA32_MISC_ENABLE` Model Specific Register (MSR).
- **Note:** This workaround carries a significant performance penalty for memory operations.
## Detection
- **Indicators of Compromise:** Unexplained system instability, spontaneous reboots, or `Machine Check Exception` logs in system telemetry.
- **Detection methods and tools:** CPU feature flags can be checked to see if a processor is in the affected family. Researchers used "Oracle Serialization" fuzzing (e.g., Silifuzz) to identify the state discrepancy.
## References
- **Vendor Advisory:** [https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00950.html]
- **Technical Analysis:** [https://googleprojectzero.blogspot.com/2023/11/reptar-mca-is-bad-actually.html] (Defanged example link)
- **Silifuzz GitHub:** [https://github.com/google/silifuzz]