Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706

Disclosure date:  2022-08-09 Published date:  2022-08-09

Severity rating:  5.5 Medium

Industry-wide severity ratings can be found in the National Vulnerability Database

Related Content

• INTEL-SA-00706

Introduction

Intel has previously documented the properties of the Enhanced Indirect Branch Restricted Speculation (eIBRS) and Indirect Branch Predictor Barrier (IBPB) capabilities, both of which can be used to help mitigate Branch Target Injection. 

The Return Stack Buffer (RSB) is a microarchitectural structure that holds predicted targets of near RET instructions. Two documented properties involving the RSB are related to this issue:

• Processors that support eIBRS¹ prevent guest software from controlling the RSB after a VM exit, as long as IA32_SPEC_CTRL.IBRS is set either at or after a VM exit.
• Software that executed before the IBPB command cannot control the predicted targets of indirect branches executed after the command on the same logical processor. The term indirect branch in this context includes near return instructions, so these predicted targets may come from the RSB.

This article uses the term RSB-barrier to refer to either an IBPB command event, or (on processors which support enhanced IBRS) either a VM exit with IBRS set to 1 or setting IBRS to 1 after a VM exit.

Issue Overview

On certain processors with eIBRS, an exception to the two above properties has been identified in some situations, shortly after an RSB-barrier: the linear address following the most recent near CALL² instruction prior to a VM exit may be used as the RSB prediction for the first near RET instruction executed after VM exit that does not have a prior corresponding CALL instruction that was also executed after VM exit. This article refers to a RET without a corresponding CALL after an RSB-barrier as an unbalanced RET.

Operating system (OS) and virtual machine manager (VMM) software that could potentially execute an unbalanced RET can use a short software sequence to mitigate this issue. Note that software which does not execute potentially affected RET instructions (such as when “RSB stuffing” is used) is not affected.

The target that may be used across an RSB-barrier is limited to the most-recent CALL prior to the barrier. A cross-barrier RSB target will not be used for RET predictions that are made after the first post-barrier CALL retires. 

This behavior is assigned CVE-2022-26373 with a base score of 5.5 (Medium) CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N.

Mitigations

The software guidance below can help VMM developers mitigate potential transient execution attacks based on the VM exit case of post-barrier return stack buffer prediction.

VM Exit

For VMMs that may execute an unbalanced RET soon after VM exit, this issue can be mitigated by specifying that a single CALL instruction has retired at some point after VM exit but before the first unbalanced RET prediction that may be used for speculative execution of a guest-controlled target. This issue does not affect balanced RETs (for example, as used in retpoline).

The following optimized instruction sequence can be employed upon VM exit prior to any unbalanced RETs:

call 1f
int3
1:
lea 0x8(%rsp), %rsp
lfence

The CALL;INT3 sequence steers a potential unbalanced RET prediction to a speculative execution barrier (INT3, in this case). The LFENCE will prevent execution of the next RET until after the prior CALL has retired, delaying predictions for any later unbalanced RETs. Where Intel® Control-Flow Enforcement Technology-Shadow Stack (CET-SS) is enabled, an INCSSP instruction could be used after this sequence to pop the address of the INT3 return site from the shadow stack.

Note that a WRMSR instruction (used to set IBRS, for example), could also serve as a speculation barrier for such a sequence in place of LFENCE. 

A 32-CALL RSB stuffing sequence³ is sufficient to prevent post-RSB-barrier RET prediction. Software already using a 32-CALL RSB stuffing sequence after VM exit does not need to apply additional mitigations for this issue.

Indirect Branch Prediction Barrier (IBPB)

Intel does not believe that any typical usage of IBPB will require additional mitigation for this issue. In most circumstances, the CALL preceding the IBPB will be in the privileged domain (and thus will not be attacker controlled). Where IBPB is invoked immediately after a VM exit, the above VM exit mitigation will also address any potential IBPB issue.

If a usage case of IBPB is identified which could be of concern, the following software mitigation alternatives could be applied.

• Execute at least one non-attacker-specified CALL prior to the IBPB command.
• Employ a mitigation sequence after the IBPB command, as described in the previous section for the VM exit case.

Enumeration

Processors which are not affected by post-barrier Return Stack Buffer predictions may indicate this by setting bit 24 of IA32_ARCH_CAPABILITIES.

IA32_ARCH_CAPABILITIES MSR

Affected Processors

Refer to the consolidated Affected Processors by CPU table (2022 tab, Post-barrier Return Stack Buffer Predictions column) for a list of processors affected by this issue. The VM exit behavior does not apply to non-eIBRS processors. Intel® Core™-based eIBRS processors are affected by both the VM exit and IBPB behavior. Intel® Atom processors are not affected. Refer to CPUID Enumeration and Architectural MSRs for eIBRS enumeration. Software can assume that all steppings for any given family/model are affected. Future processors may also be affected.

Footnotes

1. Such processors enumerate IBRS_ALL (bit 1) in the IA32_ARCH_CAPABILITIES MSR (MSR index 10AH).
2. With a non-zero displacement.
3. This 32-CALL RSB stuffing sequence may not be effective for other purposes (for example, to completely overwrite all RSB entries) on all enhanced IBRS processors, as discussed in the IBRS guidance.

Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources