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

[Sean Christopherson <seanjc@google.com>]

On Wed, Jul 29, 2026, Dmytro Maluka wrote:
> On Wed, Jul 29, 2026 at 05:28:30PM +0000, sashiko-bot@kernel.org 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.

Yeah, I have no idea what Sashiko is talking about.  The PID table is physically
addressed, AFAIK it doesn't have a TLB entry of any kind, let alone one tagged
with the vCPU's VPID.

> > 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?