List of CPU bugs, and other security-relevant hardware quirks, discovered recently (Spectre/Meltdown and later)
Most (but not all) of these only allow speculative or out-of-order access of inappropriate data, and rely on some other mechanism to leak it to the real code. They cannot modify data, except possibly indirectly (for example by leaking and using the root password, or by using them to break ASLR and combining that with something else).
One (the only?) way to do that is to speculatively access different addresses depending on the stolen data, bringing it into the cache; then, when speculation aborts, measure timing to access those addresses, revealing what value the speculation touched.
Other bugs often share a few steps with the above. All except Rosenbridge involve timing some operation that, on a simpler CPU, would be constant-time. Processors can be redesigned to block all of those; this leaves old machines vulnerable and is not considered a mitigation, though microcode update is.
Most of those issues affect only Intel processors, some are cross-vendor. Rosenbridge is the only one not applicable on Intel.
Depending on how you count, some of them may be trivial variants of each other with identical mitigations, not worth considering separate. I've split everything with a marketing name, but noted (my understanding of) how they relate to each other.
https://transient.fail/ contains a similar list of vulnerabilities.
| Marketing name | Public disclosure | Description | Links | Mitigated on Linux? |
|---|---|---|---|---|
| Spectre 1 - Bounds Check Bypass | 2018-01-03 CVE-2017-5753 |
Constructions like if (idx < limit) return foo[bar[idx]] can, if the branch is mispredicted, leak the address of foo[bar[too_big_index]], i.e. the value of bar[too_big_index] |
https://meltdownattack.com/ | Partial mitigations exist, but work is still ongoing |
| Spectre 2 - Branch Target Injection | 2018-01-03 CVE-2017-5715 |
Indirect jumps (such as virtual function calls) can be manipulated into being mispredicted, allowing speculative execution of arbitrary code, allowing simulation of devices like the above | https://meltdownattack.com/ | Yes in userspace, retpoline; work ongoing in kernel |
| Meltdown (Spectre 3) - Rogue Data Cache Load | 2018-01-03 CVE-2017-5754 |
Page access protections are not enforced during speculative execution, allowing leaking the entire kernel memory | https://meltdownattack.com/ | Yes, KPTI |
| BranchScope | 2018-03-27 CVE-2018-9056 |
Allows leaking branch predictor state, i.e. branches on secret data; may also be able to break ASLR | http://www.cs.ucr.edu/~nael/pubs/asplos18.pdf | Yes (even prior to disclosure), secret-dependent branches have always been a timing leak (though the ASLR breaks may be unmitigated) |
| Rogue System Register Read (Spectre 3a) | 2018-05-23 CVE-2018-3640 |
Various control registers are speculatively readable. Yes, it's that simple. (Though this seems to leak little if any useful information, the only useful data I can identify is a few physical addresses.) | https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html | Yes, microcode |
| Speculative Store Bypass (Spectre 4) | 2018-05-23 CVE-2018-3639 |
int* x = &secret; int** px = &x; *px = &public; attacker(*x); can speculatively access 'secret' if *px is predicted to not alias x; similarly, int bound = 0xFFFF; int* pbound = &bound; *pbound = 0x20; if (index < bound) can speculatively compare to the old value |
https://software.intel.com/security-software-guidance/api-app/sites/default/files/336996-Speculative-Execution-Side-Channel-Mitigations.pdf | Yes, microcode |
| Lazy FP State Restore (Spectre-NG) | 2018-06-13 CVE-2018-3665 |
Floating-point state is not saved and restored by the kernel on all task switches, but only if floating-point instructions are actually used by the new process. Natually, this means other processes' floating-point registers are available during speculation. | https://blog.cyberus-technology.de/posts/2018-06-06-intel-lazyfp-vulnerability.html | Yes, the correct state is now always saved and restored (patched in 2016 for performance reasons, but nobody noticed it fixed a vulnerability) |
| TLBleed | 2018-06-22 no CVE |
Hyperthreading can be used to leak TLB contents (addresses being operated on) from the sibling hyperthread | https://www.theregister.co.uk/2018/06/22/intel_tlbleed_key_data_leak/ | Yes (even prior to disclosure), secret-dependent branches and addresses have always been a timing leak |
| Bounds Check Bypass Store (Spectre 1.1) | 2018-07-10 CVE-2018-3693 |
Speculative writes (such as out-of-bounds accesses on the stack) can affect future speculative execution (such as return address), allowing speculative execution of arbitrary return addresses, like Spectre 2 | https://people.csail.mit.edu/vlk/spectre11.pdf | Same as Spectre 1? |
| Read-only protection bypass (Spectre 1.2) | 2018-07-10 can't find a CVE |
Speculative writes to read-only memory (such as code pages) succeed (the paper claims it can be used for sandbox jailbreaks, but it's unclear how - maybe it only refers to in-process sandboxes, like JavaScript engines) | https://people.csail.mit.edu/vlk/spectre11.pdf | Same as Spectre 1? |
| SpectreRSB, ret2spec | 2018-07-24 can't find a CVE |
The CPU remembers the 16 last CALL instructions, and speculatively predicts execution will continue there upon RET; much to nobody's surprise, you get Spectre 2 if the buffer runs out (not sure if SpectreRSB and ret2spec are the same bug; I think they are, independently discovered by two different teams) | https://arxiv.org/pdf/1807.07940.pdf https://christian-rossow.de/publications/ret2spec-ccs2018.pdf |
Work is ongoing, not sure how much is merged |
| NetSpectre | 2018-07-27 can't find a CVE |
Seems to just be Spectre 1 across the network, except some AVX2 part which I can't quite figure out | https://lwn.net/Articles/761100/ | Same as Spectre 1? |
| Rosenbridge | 2018-08-09 can't find a CVE |
VIA C3 processors contain an unprivileged instruction to execute a hidden internal high-privileged RISC instruction set (either a backdoor or a debug tool, depending on who you ask); it's supposed to be disabled by default, but sometimes it's left enabled | https://github.com/xoreaxeaxeax/rosenbridge https://en.wikipedia.org/wiki/Alternate_Instruction_Set |
Configure them properly, or avoid those CPUs (they're rare) |
| Foreshadow (Foreshadow-SGX) | 2018-08-18 CVE-2018-3615 |
If a page belonging to an SGX enclave is marked not readable, but data from it is present in the L1 cache, the plaintext can speculatively be read | https://foreshadowattack.eu/ | Yes, microcode |
| L1 Terminal Fault (Foreshadow NG, Foreshadow-OS) | 2018-08-18 CVE-2018-3620 |
Page table entries marked as invalid are speculatively treated as valid, allowing disclosure of the accidentally pointed-to page, if the data is present in the L1 data cache | https://foreshadowattack.eu/ (the Foreshadow-NG paper is quite easy to read) | Yes, microcode (kernel workarounds also available) |
| L1 Terminal Fault (Foreshadow NG, Foreshadow-VMM) | 2018-08-18 CVE-2018-3646 |
Guest-physical addresses are not properly translated to host-physical addresses if the page is not present (which a malicious VM can easily arrange); combined with the above, it allows speculative access to the host's entire L1 data cache | https://foreshadowattack.eu/ | Yes, microcode (kernel workarounds also available) |
| PortSmash | 2018-11-02 CVE-2018-5407 |
Yet another hyperthread leak, this one targetting how the processor can only execute a limited number of (e.g.) additions at once; doing too many reveals whether the sibling is also doing additions | https://seclists.org/oss-sec/2018/q4/123 https://github.com/bbbrumley/portsmash |
Yes for everything without secret-dependent code flow (OpenSSL missed a spot, which this bug claims credit for finding, but I don't see why that wouldn't be equally doable with TLBleed or similar) |
| Meltdown-PK, Meltdown-BR, many others | 2018-11-13 probably no CVE |
Spectre versus memory protection keys and MPX automatic bounds checks - paper claims speculative write access, but like Spectre 1.2, it's unclear how that helps (though the improper reads are bad enough) | https://arxiv.org/abs/1811.05441 https://arstechnica.com/gadgets/2018/11/spectre-meltdown-researchers-unveil-7-more-speculative-execution-attacks/ |
Probably not; Intel says it is mitigated by existing defenses, but paper says otherwise; I'd rather trust the paper |
| SPOILER | 2019-03-01 no CVE assigned |
Cache miss timing can leak pages' physical addresses, or at least virt2phys(ptr1) xor virt2phys(ptr2) | https://arxiv.org/pdf/1903.00446.pdf | The leak - no. But physical addresses are rarely used; they're useful for some other attacks (most notably Rowhammer), but most of them are mitigated by now. |
| Microarchitectural Data Sampling RIDL (MFBDS, MLPDS) Fallout (MSBDS) ZombieLoad (MFBDS) |
2019-05-14 CVE-2018-12130 CVE-2018-12126 CVE-2018-12127 CVE-2019-11091 |
No-longer-valid entries in various memory access buffers may be speculatively available, including across hyperthreads; no secret-dependent or mispredicted branches needed, EVERYTHING is vulnerable (except non-Intel) | https://www.redhat.com/en/blog/understanding-mds-vulnerability-what-it-why-it-works-and-how-mitigate-it https://mdsattacks.com/ |
Yes, microcode and kernel patch |
| RAMBleed | 2019-06-12 CVE-2019-0174 |
Rowhammer seemingly-randomly corrupts memory; apparently the corruption isn't random after all, but depends on nearby bits, allowing information leaks and worse | https://rambleed.com/ | Same as Rowhammer |
| TSX Asynchronous Abort (RIDL-TAA) | 2019-11-12 ??? |
MDS/RIDL mitigation microcode was incomplete, and left a TSX-related hole open | https://mdsattacks.com/ | Not yet |
| Plundervolt | 2019-12-16 CVE-2019-11157 |
Much to nobody's surprise, undervolting the CPU makes it misbehave. Less unsurprisingly, software can do this. Root-only, of course, but still effective against SGX enclaves. | https://www.plundervolt.com/ | Yes, microcode update to disable undervolting (or, if you're not using SGX, you're not vulnerable) |
| Vector Register Sampling L1D Eviction Sampling CacheOut |
2020-01-27 CVE-2020-0548 CVE-2020-0549 |
Looks like simple variants of Microarchitectural Data Sampling, targetting slightly different data | https://cacheoutattack.com/ https://blogs.intel.com/technology/2020/01/ipas-intel-sa-00329/ |
No, a microcode update is announced but not released yet |
| Take A Way | 2020-03-08? can't find a CVE |
AMD L1d cache timing can be abused to determine whether another process has used a particular virtual address, allowing, for example, ASLR breaks | https://mlq.me/download/takeaway.pdf | Other than the ASLR breaks, yes (even prior to disclosure), secret-dependent branches and addresses have always been a timing leak |
| Load Value Injection | CVE-2020-0551 |
It's Spectre backwards, to inject bogus data into speculative execution, to trick ordinary code into becoming Spectre gadgets | https://lviattack.eu/ | No, but the vulnerability is only applicable to SGX in practice |
| TRRespass | 2020-03-10 No CVE found |
Rowhammer but better; a more complicated form of Rowhammer can overwhelm the mitigations | https://www.vusec.net/projects/trrespass/ | No, and it's unclear whether it's possible to mitigate in either software or microcode |
| Snoop-assisted L1 Data Sampling | 2020-03-10 CVE-2020-0550 |
Like Load Value Injection, bogus data is injected into speculation; can't find any real difference | https://software.intel.com/security-software-guidance/insights/deep-dive-snoop-assisted-l1-data-sampling | Same as L1 Terminal Fault |
Other named relevant vulnerabilities, not listed above due to being older than Spectre: Rowhammer (2014-06-24), CacheBleed (2016-08-04), MemJam (2017-03-07)
Other named somewhat-relevant vulnerabilities, but which are instead software bugs in mitigations for already-known hardware issues: Grand Schemozzle (2019-08-06)