Re: [RFC PATCH v2 13/25] KVM: nSVM: Flush both L1 and L2 ASIDs on KVM_REQ_TLB_FLUSH

[Sean Christopherson <seanjc@google.com>]

On Tue, Jun 16, 2026, Yosry Ahmed wrote:
> On Mon, Jun 15, 2026 at 6:05 PM <sashiko-bot@kernel.org> wrote:
> > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > > index dac3d0098bb77..4f13c3456a5d7 100644
> > > --- a/arch/x86/kvm/svm/svm.c
> > > +++ b/arch/x86/kvm/svm/svm.c
> > [ ... ]
> > > @@ -4213,7 +4215,11 @@ static void svm_flush_tlb_all(struct kvm_vcpu *vcpu)
> > >       if (WARN_ON_ONCE(svm_hv_is_enlightened_tlb_enabled(vcpu)))
> > >               hv_flush_remote_tlbs(vcpu->kvm);
> > >
> > > -     svm_flush_tlb_asid(vcpu);
> > > +     kvm_hv_purge_all_tlb_flush_fifos(vcpu);
> > > +
> > > +     vmcb_set_flush_asid(svm->vmcb01.ptr);
> > > +     if (svm->nested.vmcb02.ptr)
> > > +             vmcb_set_flush_asid(svm->nested.vmcb02.ptr);
> >
> > [Severity: High]
> > Could this dereference of svm->nested.vmcb02.ptr cause a use-after-free?
> >
> > If svm_allocate_nested() successfully allocates vmcb02_page and assigns it
> > to svm->nested.vmcb02.ptr, but a subsequent allocation (such as msrpm)
> > fails, the error path frees the page but does not clear the pointer:
> >
> > arch/x86/kvm/svm/nested.c:svm_allocate_nested() {
> >     ...
> > err_free_vmcb02:
> >     __free_page(vmcb02_page);
> >     return -ENOMEM;
> > }
> >
> > If a TLB flush is later triggered and calls svm_flush_tlb_all(), the check
> > for if (svm->nested.vmcb02.ptr) would evaluate to true on the dangling
> > pointer, and vmcb_set_flush_asid() would write to freed memory.
> >
> > Would it be safer to check svm->nested.initialized here instead, to ensure
> > the nested state is fully allocated and valid?
> 
> Yes. But if no one objects, I'd rather add a patch to drop
> svm->nested.initialized completely, and properly NULLify
> svm->nested.vmcb02.ptr in the destruction paths. Keying off the
> pointer makes more sense semantically imo.

+1