A bug in Linux 6.2 allowed bypassing Specter v2 attack protection

Recently, information was released about a vulnerability identified in Linux 6.2 kernel (already listed under CVE-2023-1998) and which stands out because it is disable Specter v2 attack protection which allow access to memory by other processes running on different SMT or Hyper Threading threads, but on the same physical processor core.

Vulnerability is notable among other things because can be used for organize data leakage between virtual machines in cloud systems. 

For those who don't know about Spectre, they should know that this is one of the two original transient execution CPU vulnerabilities (the other is Meltdown), which involve microarchitectural timing side-channel attacks. These affect modern microprocessors that perform jump predictions and other forms of speculation.

On most processors, speculative execution resulting from a wrong branch prediction can leave observable side effects that can reveal private data. For example, if the pattern of memory accesses made by such a speculative execution depends on the private data, the resulting state of the data cache constitutes a side channel through which an attacker can extract information about the private data using a time attack.

Since the disclosure of Specter and Meltdown in January 2018, several variants and new types of vulnerability related to them have emerged.

The Linux kernel allows userland processes to enable mitigations by calling prctl with PR_SET_SPECULATION_CTRL, which disables the spec function, as well as by using seccomp. We found that on virtual machines from at least one major cloud provider, the kernel still left the victim process open to attack in some cases, even after enabling specter-BTI mitigation with prctl. 

Regarding vulnerability, it is mentioned that in user space, to protect against attacks of Spectre, processes can selectively disable execution speculative instructions with prctl PR_SET_SPECULATION_CTRL or use seccomp-based system call filtering.

According to the researchers who identified the problem, incorrect optimization in kernel 6.2 left virtual machines from at least one large cloud provider without proper protection despite the inclusion of the specter-BTI attack blocking mode via prctl. The vulnerability also manifests itself on normal servers with kernel 6.2, which are started with the configuration "spectre_v2=ibrs".

The essence of vulnerability is that by choosing the modes of protection IBRS or eIBRS, the optimizations made disabled the use of the STIBP (Single Thread Indirect Branch Predictors) mechanism, which is necessary to block leaks when using Simultaneous Multi-Threading (SMT or Hyper-Threading) technology. )

In turn, only the eIBRS mode provides protection against leaks between threads, not the IBRS mode, since with it the IBRS bit, which provides protection against leaks between logical cores, is cleared for performance reasons when control returns to the space user, which makes user-space threads unprotected against attacks from the Specter v2 class.

The test consists of two processes. The attacker constantly poisons an indirect call to speculatively redirect it to a destination address. The victim process measures the wrong prediction rate and tries to mitigate the attack by calling PRCTL or writing to the MSR directly using a kernel module that exposes the MSR read and write operations in user space.

The problem affects only the Linux 6.2 kernel and is due to incorrect implementation of optimizations designed to reduce significant overhead when applying protection against Specter v2. vulnerability It was fixed in the experimental Linux 6.3 kernel branch.

Finally yes you are interested in being able to know more about it, you can check the details in the following link