summaryrefslogtreecommitdiff
path: root/scripts
diff options
context:
space:
mode:
authorDmytro Maluka <dmaluka@chromium.org>2026-07-29 17:06:21 +0000
committerSean Christopherson <seanjc@google.com>2026-07-31 15:13:31 -0700
commitb41f2ca6c06011c36b75f5d53aa17c05ed90be21 (patch)
treea0d88780189effcfda0ed381faf2c92e2348cf3a /scripts
parent97d65b544f48b2ee49f6aea32145e3e7969955dc (diff)
downloadlinux-b41f2ca6c06011c36b75f5d53aa17c05ed90be21.tar.gz
linux-b41f2ca6c06011c36b75f5d53aa17c05ed90be21.zip
KVM: VMX: Fix stale PID-pointer table entry left after vCPU free
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. [*] Fix this by clearing the pid_table entry when destroying the vCPU. Note that the same issue exists for SVM AVIC as well [1], to be fixed. [*] Although, since this memory is freed into the kvm_vcpu_cache kmem cache which is only used for allocating kvm_vcpus, _maybe_ this memory will only be reused for pi_desc of another vCPU, not for anything else. So _maybe_ this will only result in delivering the IPI to a wrong vCPU (possibly of another VM) in the worst case, not in a random corruption of kernel memory. Link: https://lore.kernel.org/kvm/al4rNqpBYy8FGKPw@blrnaveerao1 [1] Signed-off-by: Dmytro Maluka <dmaluka@chromium.org> Reviewed-by: Kai Huang <kai.huang@intel.com> Link: https://patch.msgid.link/20260729170621.308809-3-dmaluka@chromium.org Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'scripts')
0 files changed, 0 insertions, 0 deletions