Re: [PATCH] KVM: nVMX: Re-arm the vmcs12 pages request if mapping the pages fails

[Sean Christopherson <seanjc@google.com>]

On Thu, Aug 13, 2026, Jinwoo Lee wrote:
> However, I do not currently see evidence that the SVM failures have the
> same unpinned-HPA/UAF mechanism as the nVMX APIC-backed VMCS02 fields.

Eh, doesn't really matter.  It's still ugly/flawed code that we should fix,
especially since fixing this in a common location should be a net reduction in
code.

> In particular, nested_vmcb02_prepare_control() initially copies
> vmcb01's KVM-owned MSRPM address into vmcb02, and
> nested_svm_merge_msrpm() switches vmcb02 to the KVM-owned merged MSRPM
> only after the merge completes successfully.  Losing the request after
> a failed merge can therefore allow L2 to run without L1's complete MSR
> intercept state, but it does not appear to leave hardware pointing at an
> unpinned guest page.  I will describe and test the SVM impact separately
> instead of treating it as the same UAF without supporting evidence.
> 
> > Does this allow L2 to resume with unpinned HPAs and lead to a
> > use-after-free?
> 
> Not uniformly across these paths.  The unpinned-HPA mechanism is the
> concern for the nVMX VMCS02 address fields described in the patch, but I
> have not yet reproduced host-page reuse or an actual use-after-free end
> to end.  For eVMCS and SVM, the current evidence establishes that the
> deferred setup request can be lost; it does not yet establish the same
> unpinned-HPA mechanism.
> 
> I will also correct the commit message.  Not every failure reports
> KVM_EXIT_INTERNAL_ERROR: the load_pdptrs() failure used by my RSM
> reproducer returns with exit_reason unchanged, which is
> KVM_EXIT_UNKNOWN in the test.

Heh, which as I pointed out in my other reply, is a bug, not intentional.