Merge pull request #571 from speed47/test

built from commit 0045d237fa
 dated 2026-06-01 20:44:44 +0000
 by Stéphane Lesimple (speed47_github@speed47.net)

 Prepare next release

README.md

@@ -40,6 +40,14 @@ CVE | Name | Aliases
 [CVE-2024-45332](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-45332) | Branch Privilege Injection | BPI
 [CVE-2025-54505](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-54505) | AMD Zen1 Floating-Point Divider Stale Data Leak | FPDSS
 
+The following entries are ARM64 silicon errata that the kernel actively works around. They have no assigned CVE; they are tracked only by ARM's erratum numbers. Select them with `--errata <number>` or the associated `--variant` mnemonic.
+
+ID | Name | Affected cores
+-- | ---- | --------------
+CVE-0001-0001 | Speculative AT TLB corruption (errata 1165522, 1319367, 1319537, 1530923) | Cortex-A55/A57/A72/A76
+CVE-0001-0002 | Speculative unprivileged load (errata 2966298, 3117295) | Cortex-A510/A520
+CVE-0001-0003 | MSR SSBS not self-synchronizing (erratum 3194386 + siblings) | Cortex-A76/A77/A78/A78C/A710/A715/A720/A720AE/A725, X1/X1C/X2/X3/X4/X925, Neoverse-N1/N2/N3/V1/V2/V3/V3AE
+
 ## Am I at risk?
 
 Depending on your situation, the table below answers whether an attacker in a given position can extract data from a given target.
@@ -272,23 +280,23 @@ In **Hardware-only** mode, the script only reports CPU information and per-CVE h
 
 - Get the latest version of the script using `curl` *or* `wget`
 
-```bash
+    ```bash
-curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
+    curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
-wget https://meltdown.ovh -O spectre-meltdown-checker.sh
+    wget https://meltdown.ovh -O spectre-meltdown-checker.sh
-```
+    ```
 
 - Inspect the script. You never blindly run scripts you downloaded from the Internet, do you?
 
-```bash
+    ```bash
-vim spectre-meltdown-checker.sh
+    vim spectre-meltdown-checker.sh
-```
+    ```
 
 - When you're ready, run the script as root
 
-```bash
+    ```bash
-chmod +x spectre-meltdown-checker.sh
+    chmod +x spectre-meltdown-checker.sh
-sudo ./spectre-meltdown-checker.sh
+    sudo ./spectre-meltdown-checker.sh
-```
+    ```
 
 ### Using a docker container
 

doc/UNSUPPORTED_CVE_LIST.md

@@ -307,3 +307,13 @@ A weakness in AMD's microcode signature verification (AES-CMAC hash) allows load
 Exploits a synchronization failure in the AMD stack engine via an undocumented MSR bit, targeting AMD SEV-SNP confidential VMs. Requires hypervisor-level (ring 0) access.
 
 **Why out of scope:** Not a transient/speculative execution side channel. This is an architectural attack on AMD SEV-SNP confidential computing that requires hypervisor access, which is outside the threat model of this tool.
+
+## No CVE — Jump Conditional Code (JCC) Erratum
+
+- **Issue:** [#329](https://github.com/speed47/spectre-meltdown-checker/issues/329)
+- **Intel whitepaper:** [Mitigations for Jump Conditional Code Erratum](https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf)
+- **Affected CPUs:** Intel 6th through 10th generation Core and Xeon processors (Skylake through Cascade Lake)
+
+A microarchitectural correctness erratum where a conditional jump instruction that straddles or ends at a 64-byte instruction fetch boundary can corrupt the branch predictor state, potentially causing incorrect execution. Intel addressed this in a November 2019 microcode update. Compilers and assemblers (GCC, LLVM, binutils) also introduced alignment options (`-mbranch-alignment`, `-x86-branches-within-32B-boundaries`) to pad jump instructions away from boundary conditions, preserving performance on CPUs with updated microcode.
+
+**Why out of scope:** The JCC erratum is a microarchitectural correctness bug, not a transient or speculative execution side-channel vulnerability. No CVE was ever assigned. Red Hat noted that privilege escalation "has not been ruled out" but made no definitive security finding, and no exploit has been demonstrated. There is no Linux sysfs entry, no CPUID bit, and no MSR flag exposing the mitigation status. The microcode fix introduces no detectable hardware indicator, so checking for it would require maintaining a per-CPU-stepping minimum microcode version table (the design principle 3 exception) — costly to maintain without a CVE anchor or confirmed exploitability to justify the ongoing work. The kernel compiler mitigation is a build-time-only change (instruction alignment) with no observable runtime state.