diff options
| author | Dmytro Maluka <dmaluka@chromium.org> | 2026-07-29 17:06:21 +0000 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2026-07-31 15:13:31 -0700 |
| commit | b41f2ca6c06011c36b75f5d53aa17c05ed90be21 (patch) | |
| tree | a0d88780189effcfda0ed381faf2c92e2348cf3a /scripts | |
| parent | 97d65b544f48b2ee49f6aea32145e3e7969955dc (diff) | |
| download | linux-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
