CWE-1423 describes shared microarchitectural predictor state that lets code influence transient execution across a hardware boundary, potentially exposing data accessible beyond that boundary over a covert channel.
It matters to chip designers, operating system and hypervisor vendors, and compiler teams, and indirectly to anyone running code from different trust levels on one machine.
How it happens
Processors give software real boundaries: virtual memory, privilege rings, trusted execution environments and virtual machines. Two processes, for instance, cannot normally read each other's memory.
Predictors are different. A branch predictor learns from past behavior, and if its state is shared across a boundary, code on one side can train it. When that predictor causes transient execution on the other side, the attacker can influence what the victim speculatively executes, and then read the side effects.
Observed examples in the record:
- CVE-2022-0001: shared branch history state may allow user mode code to influence transient execution in the kernel, potentially exposing kernel data.
- CVE-2021-33149: return stack buffer underflow, where shared state may let code run before a prediction barrier influence transient execution after it.
What an attacker gains
Confidentiality: reading memory, medium likelihood.
How to find it
- Manual analysis. Look for predictor state shared between hardware threads or execution contexts.
- Vendor tools. Tools can try a vulnerable code sequence transiently and check for leakage.
- Taint analysis. In hardware, label each predictor entry or history by the context that created it, then look for use across contexts.
How to fix it
MITRE's mitigations and ratings:
- Tag predictor entries. For example with a kernel mode bit, so a prediction in the current mode must have been trained in that mode. Tags can also tie an entry to the SMT thread that made it. Rated moderate. It works well for discrete elements such as an array of branch targets, but poorly where state is a compressed digest of history.
- Sanitize predictor state on a context change such as a system call, or expose instructions so the operating system can do it on a process switch. Rated moderate. It may not help with state shared across SMT threads and can cost performance.
- System software invokes the sanitizing operation, such as the indirect branch prediction barrier on Intel x86, when switching contexts, following vendor recommendations. Rated moderate.
- Change compiler output so the affected instruction is not generated. Retpoline is the prominent example. Rated limited, because it only protects code built with it and may be fully effective on some processors but not others.
- Block covert channels in hardware, which MITRE notes has many pitfalls.
Operating system, hypervisor and firmware updates carry most of these software side measures, so keeping them current is the practical step for most teams.
Quick check
What does tagging a predictor entry accomplish?
It records which context created the entry, so a prediction can be limited to entries trained in the same mode or by the same SMT thread.
Why is retpoline rated limited?
It only covers software compiled with it, and its effectiveness differs across processors.
