Re: [PATCH v2 2/2] KVM: VMX: Fix stale PID-pointer table entry left after vCPU free

On Wed, Jul 29, 2026 at 05:28:30PM +0000, [email protected] wrote:
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index 6b96f7aea20bd..ebf26ea84a50b 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -7572,6 +7572,9 @@ void vmx_vcpu_free(struct kvm_vcpu *vcpu)
> >  	nested_vmx_free_vcpu(vcpu);
> >  	free_loaded_vmcs(vmx->loaded_vmcs);
> >  	free_page((unsigned long)vmx->ve_info);
> > +
> > +	if (vmx_can_use_ipiv(vcpu))
> > +		WRITE_ONCE(to_kvm_vmx(vcpu->kvm)->pid_table[vcpu->vcpu_id], 0);
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but does clearing the pid_table
> entry alone prevent hardware from writing to the freed pi_desc?
> 
> According to the Intel SDM (Section 29.1.5), the processor caches PID-pointer
> table entries in the VPID.

I can't find this statement in the SDM, and I'm not sure what it has to
do with VPID, apart from the acronym similarity.

> Because KVM immediately frees the vcpu memory into kvm_vcpu_cache after
> kvm_arch_vcpu_destroy() without issuing a cross-vCPU flush (e.g., via
> kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) to invalidate the VPID
> caches of other running vCPUs and synchronize with in-flight IPI deliveries,
> can other vCPUs still send hardware IPIs using the cached pi_desc pointer?
> 
> Could this result in the IPI hardware writing to the freed vcpu memory and
> corrupting another newly created vCPU when the memory is reused from
> kvm_vcpu_cache?
> 
> >  }
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2