Disclosure date: 2025-05-12 Published date: 2025-05-12 |
![]() Severity rating: 4.7 Medium |
Industry-wide severity ratings can be found in the National Vulnerability Database |
Related Content
- INTEL-SA-01153
- Linux* kernel commit for ITS
- Linux kernel commit for IBTI History
- Branch History Injection and Intra-mode Branch Target Injection
Overview
Recent Intel processors support a technology called enhanced IBRS (eIBRS) for mitigating Branch Target Injection transient execution attacks. Processors affected by the Indirect Target Selection (ITS) issue may incompletely mitigate Branch Target Injection, due to indirect branch predictions that are not fully constrained by the enhanced IBRS properties, nor by the IBPB (Indirect Branch Prediction Barrier) indirect barrier.
There are several documented properties that may be violated by this Indirect Target Selection issue. Firstly, when IBRS is set on these processors, predicted targets of indirect branches of a virtual machine manager (VMM) (VMX root) should not be controlled by software that was executed in a virtual machine (VM) (VMX non-root). Secondly, branches in system management mode (SMM) and Intel® Software Guard Extensions (Intel® SGX) enclaves cannot be controlled by outside code. Finally, software that executed before an IBPB barrier should not be able to control the predicted targets of indirect branches executed after the barrier on the same logical processor.
Intel is providing a microcode update for this issue, which ensures that these targets are cleared when OS/VMM software invokes an Indirect Branch Prediction Barrier (IBPB), and in other similar circumstances, such as when entering an Intel SGX enclave and/or SMM. This prevents potential transient execution attacks in situations where these unintended targets may otherwise correspond to branches prior to these barriers.
Intel is also issuing VMM software guidance for some processors where indirect branches in a VMM (VMX host) may be predicted using unintended targets corresponding to branches in a guest. This guidance is only relevant where VMM software is relying on enhanced IBRS (eIBRS) to mitigate Branch Target Injection attacks.
The recommendations in this article are applicable to situations where transient execution attacks are within the user's threat model. Generally, transient execution attacks require an attacker to be able to run code on the same machine (or the same virtual machine) as the data they are attempting to read, but do not have access to the data (such as where privilege-level isolation is in place).
Some recent processors (from processors code named Alder Lake and Sapphire Rapids onward, as well as Intel® Atom processors) are not affected by this issue and do not require either the microcode update or any software changes; consult the list of affected processors for more details. In particular, no processors which support Intel® Trust Domain Extensions (Intel® TDX) are affected by this issue.
Indirect Target Selection is assigned CVE-2024-28956 with a CVSS score of 4.7 (Medium) CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N.
Mitigation
Indirect Branch Predictor Barrier (IBPB)
Intel is providing a microcode update to ensure that indirect branches predicted after an indirect branch prediction barrier (IBPB), are not predicted using a branch target which corresponds to a branch from software executed prior to the barrier.
Intel® Software Guard Extensions (Intel® SGX) and SMM
Intel is providing a microcode update to ensure that indirect branches predicted in an Intel SGX enclave or in SMM are not predicted using a branch target outside those SMM or Intel SGX modes.
Operating Systems
On affected processors, indirect branches in the OS kernel may be predicted using targets which correspond to aliased direct branches in the same predictor mode, making it possible to perform Intra-mode Branch Target Injection attacks with these additional targets. This may be a security concern in some situations, such as where attackers may be able to control direct branches in supervisor mode using managed runtimes such as cBPF, or where vulnerable pairs of aliasing branches have been identified which cannot be mitigated on an individual basis.
In such cases, operating system software can mitigate Indirect Target Selection by applying the techniques described in the VMM Software section when running on an affected processor. Operating system software running in a virtualized environment may also wish to apply such mitigations where IA32_ARCH_CAPABILITIES[62] (ITS_NO) is not enumerated even when the family/model/stepping enumerated by CPUID is not affected. Refer to the Migration Pools section for details.
This issue does not affected the eIBRS property that indirect branches in supervisor code should not be predicted using targets corresponding to userspace branches.
Virtual Machine Manager (VMM) Software
On a subset of affected processors, indirect branches in a VMM (VMX host) may be predicted using targets which correspond to branches in a guest. VMM software may need to apply additional mitigations (described below) if all of the following are true:
- The VMM is relying on enhanced IBRS’s guest/host isolation for mitigating Branch Target Injection attacks by guests against the VMM itself. Note that, as implied in the OS section above, indirect branch target predictions of host supervisor code are still not predicted using targets corresponding to guest userspace addresses.
- The VMM is not itself virtualized (meaning the hypervisor present bit (CPUID.1.ECX[31]) is 0), since nested VMMs rely on their L0 hypervisor rather than enhanced IBRS to isolate the nested VMM from its guests.
- The family/model/stepping enumerated by CPUID is in the list below:
Table 1: Processors which require additional VMM mitigations CPUID Family_Model Stepping Code Name / Microarchitectures Product Family 06_55H 6 Cascade Lake Server 2nd Generation Intel® Xeon® Scalable processor family 06_55H 7 1. Cascade Lake Server
2. Cascade Lake W
3. Cascade Lake X1. 2nd Generation Intel® Xeon® Scalable processor family
2. Intel® Xeon® W processor family
3. Intel® Core™ X-series Processor06_55H B Cooper Lake 3rd Generation Intel® Xeon® Scalable processor family 06_8EH C 1. Whiskey Lake U
2,3,4. Comet Lake U42
5. Amber Lake Y1. 8th Generation Intel® Core™ Processors
2. 10th Generation Intel® Core™ Processor Family
3. Intel® Pentium® Gold Processor Series
4. Intel® Celeron® Processor 5000 Series
5. 10th Generation Intel® Core™ Processor Family06_9EH D 1. Coffee Lake H
2. Coffee Lake Xeon E
3. Coffee Lake S1. 9th Generation Intel® Core™ Processor Family
2. Intel® Xeon® E processor family
3. 9th Generation Intel® Core™ Processor Family06_A5H 2, 3, 5 Comet Lake S
Comet Lake H10th Generation Intel® Core™ Processor Family
Intel® Xeon® W processor family
Intel® Pentium® Gold Processor Family
Intel® Celeron® Processor Family
Intel® Xeon® W processor family06_A6H 0, 1 Comet Lake U62 10th Generation Intel® Core™ Processor Family
Intel® Xeon® W processor family
- The family/model/stepping enumerated by CPUID is in the list below:
Where all of these conditions apply, VMM software can mitigate this issue by ensuring that the last byte of all indirect branch instructions in host VMM code are located in the last 32 bytes of a 64-byte cache line (referred to as the “second” half). Alternatively, host VMM code can use out-of-line thunk functions to invoke indirect branches. In particular, indirect jmp/call/ret instructions can be replaced with a direct branch to an indirect thunk which has an indirect jmp/call/ret branch with the last byte in the “second” half of the cache line. Multiple thunks can be used to address any potential performance or security concerns due to the mitigation sharing a single branch in a thunk between many different indirect branches.
This mitigation may need to be applied to all code in ring 0 of the VMM host, including OS code where relevant.
Note that this issue only applies to indirect branch instructions (including RETs) which have their last byte in the first 32 bytes of a 64-byte cache line (the “first” half).

The processors where VMM host software may be affected by this issue also enumerate RRSBA, and so (as previously documented) RET instructions may be predicted using alternate predictors and thus may be affected by this issue. Note that retpoline is not typically applied to all RET instructions, and so VMM software may need to apply further mitigations.
Migration Pool
VM migration pools may contain both affected and unaffected processors. To help VMMs communicate to the guest whether they are affected by Indirect Target Selection, IA32_ARCH_CAPABILITIES[62] will be defined as ITS_NO. A VMM can enumerate this bit as 1 to guests in order to indicate that they are not affected by Indirect Target Selection.
The VMM should synthesize ITS_NO for VMs unless the VM could run on an affected host.
The algorithm for an OS to determine if it is affected can be found in the Enumeration section.
Enumeration
Register Address Hex | Register Address Dec | Architectural MSR Name / Bit Fields | MSR / Bit Description | Comment |
---|---|---|---|---|
10AH | 266 | IA32_ARCH_CAPABILITIES | Enumeration of Architectural Features (RO) | If CPUID.(EAX-07H, ECX=0):EDX[29]=1 |
10AH | 266 | 62 | ITS_NO If 0, the hypervisor indicates that the system may be affected by Indirect Target Selection If 1, the hypervisor indicates that the system is not affected by Indirect Target Selection |
FMS inside a guest may be different from host (for example, if the host is a Cascade Lake server and guest has FMS of Skylake). This bit is provided for hypervisor to indicate to guest that it could be affected by ITS regardless of its FMS. Not expected to be set by hardware. |
10AH | 266 | 63 | MSR_VIRTUAL_ENUMERATION_SUPPORTED If 0, MSR_VIRTUAL_ENUMERATION is not supported If 1, MSR_VIRTUAL_ENUMERATION is supported |
VMM will set this bit for the guest as a communication channel. Currently, it is used for sharing mitigation status. Not expected to be set by hardware. |
The algorithm for an operating system to determine if it is affected by Indirect Target Selection is:
If (CPUID.(EAX=01H).ECX[HYPERVISOR(bit 31)]) // In a guest {
If ((IA32_ARCH_CAPABILITIES [ITS_NO]==0) AND (CPUID.(EAX=07H, ECX=02H).EDX[BHI_CTRL] == 0))
Then Affected by ITS
} else // In a host {
If ((IA32_ARCH_CAPABILITIES[IBRS_ALL]==1) && CPUID Family/Model/stepping matches the affected processor table list)
Then Affected by ITS
}
Note that no processor, including unaffected processors, is expected to enumerate ITS_NO. The above algorithms only requires that VMMs virtualize ITS_NO as 1 to guests, not that unaffected processors enumerate ITS_NO as 1.
Affected Processors
Refer to the consolidated Affected Processors table for a complete list of processors affected by Indirect Target Selection (ITS). A summary is described below:
- Indirect Target Selection with cBPF involves an indirect branch being predicted with a branch predictor entry from a direct branch in the same security domain (from cBPF)
- Affected processors list is the same list as ITS without cBPF.
- Cascade Lake, Cooper Lake, Ice Lake (client), Tiger Lake, Whiskey Lake, Comet Lake, Amber Lake, Rocket Lake
- Software using the thunk mitigation mechanism described in the Operating System section above is applicable.
- Affected processors list is the same list as ITS without cBPF.
- Indirect Target Selection without cBPF involves an indirect branch being predicted with a branch predictor entry from a direct branch in a different security domain or across an indirect branch prediction barrier (IBPB).
- Affected processor list for Guest/Host isolation is a subset of ITS without cBPF processors.
- Cascade Lake, Cooper Lake, Whiskey Lake, Comet Lake, Amber Lake
- Mitigation for guest/host isolation using the thunk mitigation mechanism described in the Operating System section above is applicable for the VMM.
- IBPB MCU mitigation is available for all ITS without cBPF involved processors.
- Affected processor list for Guest/Host isolation is a subset of ITS without cBPF processors.