[PATCH v2 0/2] KVM: VMX: Fix IPIv use-after-free + improve checking duplicate vcpu_id

[Dmytro Maluka]

vCPU creation in kvm_vm_ioctl_create_vcpu() may fail after
kvm_arch_vcpu_create() -> vmx_vcpu_create() already succeeded. In such
case kvm_vm_ioctl_create_vcpu() destroys the newly created vCPU in the
failure path. However, that leaves a side effect: the IPIv pid_table
entry remains configured with this vCPU's pi_desc address. As a result,
when another vCPU sends an IPI to the APIC ID of this failed-to-create
vCPU, it will cause HW to write to this (freed!) pi_desc memory.

The straightforward way to fix this is to clear the pid_table entry in
vmx_vcpu_free(), which is what patch 2 in this series does.

But that requires addressing a related meta-issue first: if userspace
tries to create a vCPU with the same vcpu_id as an existing one,
kvm_vm_ioctl_create_vcpu() checks for that and fails with -EEXIST only
after it already created the vCPU via kvm_arch_vcpu_create(). As a
result, clearing the pid_table entry in the vmx_vcpu_free() in the
failure path would clear the pid_table entry for that already existing
good vCPU, i.e. effectively disable IPIv for that vCPU.

For this reason, the v1 patch [1] addressed the IPIv issue by postponing
the pid_table entry setup until kvm_arch_vcpu_postcreate() when we are
sure that the vCPU creation succeeded, instead of clearing it when
destroying the vCPU.

However, as pointed out by Sean [2], insufficient validation of vcpu_id
before calling kvm_arch_vcpu_create() is a potential source of a whole
class of similar issues, so it's better to fix this meta-issue once and
for all. Another concern about the v1 approach is that initializing vCPU
state in vcpu_postcreate, after the vCPU is already reachable, is
generally tricky.

So patch 1 in this series moves checking for duplicated vcpu_id in
kvm_vm_ioctl_create_vcpu() earlier, before creating the vCPU. To do that
without races, it introduces the kvm->vcpu_ids bitmap (see patch 1
description for the details). It is a slightly adjusted version of
Sean's bitmap patch from [2].

P.S. Note that the same IPIv use-after-free issue exists on SVM as well,
as pointed out by sashiko and confirmed by Naveen [3]. This remains to
be fixed. (Supposedly it is as trivial to fix as for VMX, but I'll leave
that to someone who's familiar with that and has AMD hardware.)

[1] https://lore.kernel.org/kvm/20260716160801.3155582-1-dmaluka@xxxxxxxxxxxx/
[2] https://lore.kernel.org/kvm/al6eg7C-2sDBEAFD@xxxxxxxxxx/
[3] https://lore.kernel.org/kvm/al4rNqpBYy8FGKPw@blrnaveerao1/

Dmytro Maluka (2):
  KVM: Check for duplicate vcpu_id as early as possible
  KVM: VMX: Fix stale PID-pointer table entry left after vCPU free

 arch/x86/kvm/vmx/vmx.c   | 3 +++
 include/linux/kvm_host.h | 1 +
 virt/kvm/kvm_main.c      | 9 ++++++++-
 3 files changed, 12 insertions(+), 1 deletion(-)

-- 
2.55.0.508.g3f0d502094-goog