GhostRace Detailed - Speculative Race Conditions Affecting All Major CPUs / ISAs

VUSec and IBM Research Europe today announced Speculative Race Conditions (SRCs) as a as a new class of vulnerabilities where thread synchronization primitives using conditional branches can be microarchitecturally bypassed on speculative paths using a Spectre-V1 attack. The researchers have dubbed CVE-2024-2193 as GhostRace and is said to affect all major CPU vendors.

GhostRace / Speculative Race Conditions are around thread synchronization primitives like mutexes and in the context of conditional branches with a Spectre Variant One attack could lead to leaking information from the target paper.

Among the key takeaways on the GhostRace page by VUSec:

Our analysis shows all the other common write-side synchronization primitives in the Linux kernel are ultimately implemented through a conditional branch and are therefore vulnerable to speculative race conditions.
...
Hardware: We have confirmed that all the major hardware vendors are affected by SRCs since, regardless of the particular compare-and-exchange instruction implementation, the conditional branch that follows is subject to branch (mis)prediction. In other words, all the microarchitectures affected by Spectre-v1 are also affected by SRCs.

Software: Any target relying on conditional branches to determine whether to enter critical regions—a common design pattern that extends well beyond Linux—is vulnerable to SRCs.

In summary, any software, e.g., operating system, hypervisor, etc., implementing synchronization primitives through conditional branches without any serializing instruction on that path and running on any microarchitecture (e.g., x86, ARM, RISC-V, etc.), which allows conditional branches to be speculatively executed, is vulnerable to SRCs. As in other speculative execution attacks, this allows leaking data from the target software.
...
To address the new attack surface, we also propose a generic SRC mitigation to serialize all the affected synchronization primitives on Linux (i.e., adding an lfence instruction after the lock cmpxchq in Figure 1). Our mitigation requires minimal kernel changes (i.e., 2 LoC) and incurs only ≈5% geomean performance overhead on LMBench.

Linux kernel developers do not plan on implementing the researcher's proposed serialization of synchronization primitives due to performance concerns. Similarly, AMD's security bulletin on Speculative Race Conditions notes that AMD recommends just following previously-published guidance around Spectre mitigations.

We'll see if anything changes but as of now both the hardware vendors and the upstream Linux kernel developers don't feel it's necessary taking any new steps around GhostRace / Speculative Race Conditions.