Branch Privilege Injection: Exploiting branch predictor race conditions

Vulnerability & Scope

  • New Spectre-class issue: a race in Intel’s branch predictor lets attacker-controlled user code influence predictions used in more-privileged contexts, leaking arbitrary memory (PoC reaches ~5 KB/s, enough to eventually dump all RAM).
  • Affects all Intel CPUs from Coffee Lake Refresh (9th gen) onward; researchers also observe predictor behavior bypassing IBPB as far back as Kaby Lake, though exact exploitability per model is unclear.
  • Authors report no issues on evaluated AMD and ARM systems. Commenters stress this is one member of a large “speculative execution” family, not a single bug.

Relation to Spectre / Training Solo

  • Both this and Training Solo are Spectre v2-style attacks on indirect branches:
    • Training Solo: attacker in kernel mode “self-trains” mispredictions to a disclosure gadget.
    • Branch Privilege Injection: attacker’s user-mode training updates are still in flight when privilege changes; updates get applied as if they were made in kernel mode, steering a privileged branch to a gadget.

Performance vs. Security

  • Heavy debate on branch prediction:
    • Many emphasize it’s fundamental for modern deep pipelines; without it, stalls would be catastrophic.
    • Others fantasize about simpler or static predictors, or even disabling prediction, but acknowledge large slowdowns (lfence-everywhere estimated ~10×; static prediction seen as 20–30% hit).
  • Paper reports microcode mitigation overhead up to ~2.7% on Alder Lake; software-only strategies evaluated between ~1.6% and 8.3% depending on CPU.
  • Some argue cumulative mitigations have eroded much of the headline performance gains of the last decade.

Mitigations, OSes & Microcode

  • Intel advisory (INTEL-SA-01247) and microcode (20250512) released; embargo ended May 13.
  • All major OSes are said to have mitigations/microcode paths; Windows press text mentioned explicitly, with comments clarifying Linux gets Intel microcode via distro packages.
  • Long side-thread on whether Ubuntu 24.04 LTS is “up to date”:
    • One side: LTS with security backports is what production actually runs, thus relevant.
    • Other side: LTS kernels are effectively distro forks, not representative of current mainline mitigations.

Cloud, VMs & Isolation

  • Concern over cross-VM leaks in shared-cloud CPUs.
  • Memory-encryption features (Intel TME-MK, AMD SEV) are noted but characterized as insufficient for this style of side channel, since leakage comes from microarchitectural behavior, not direct DRAM reads.
  • Suggestions: pin VMs or security domains to separate cores/SMT siblings, and design OS/hypervisors to avoid co-locating different privilege levels on one core—though practicality and completeness of this approach are debated.

Web Exploitability & Risk Appetite

  • Strong disagreement over real-world risk:
    • Some insist these require “insane prep,” are unlikely to be exploited from JavaScript, and disable mitigations for performance on trusted boxes.
    • Others point out Spectre was demonstrated from JS, that JITted code is effectively low-level, and that browser timer fuzzing only slows, not eliminates, such attacks.
    • Several warn that deciding a system is “safe” to disable mitigations is tricky: CI servers, databases with stored procedures, and dependencies all amount to running semi-arbitrary code.

Architecture & Long-Term Outlook

  • Ideas raised: capability-style pointers (CHERI), richer pointer metadata, or resurrecting segmentation-like mechanisms; pushback that hardware, not language choice, is the core constraint.
  • Many expect speculative-execution side channels to keep appearing; mitigations are seen as an ongoing performance–security trade that’s unlikely to end while we run untrusted, Turing-complete web code on high-performance CPUs.