Re: [PATCH v2 1/2] KVM: VMX: Explicitly track TDX VMs' root level instead of guessing it from CPUID

[Sean Christopherson <seanjc@google.com>]

On Wed, Aug 26, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index 064ecc33b9267..611c78be8b411 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> [ ... ]
> > @@ -5953,19 +5953,22 @@ void __kvm_mmu_refresh_passthrough_bits(struct kvm_vcpu *vcpu,
> >  
> >  static inline int kvm_mmu_get_tdp_level(struct kvm_vcpu *vcpu)
> >  {
> [ ... ]
> >  	/* tdp_root_level is architecture forced level, use it if nonzero */
> >  	if (tdp_root_level)
> >  		return tdp_root_level;
> >  
> > +	/*
> > +	 * If the VM has mirror roots, then the root level is predefined as the
> > +	 * mirror root (and by extension the normal root) needs to match the
> > +	 * root level that was configured for the external page tables that are
> > +	 * being mirrored by KVM.
> > +	 */
> > +	if (kvm_has_mirrored_tdp(vcpu->kvm) &&
> > +	    !WARN_ON_ONCE(!vcpu->kvm->arch.mirror_root_level))
> > +		return vcpu->kvm->arch.mirror_root_level;
> 
> [Severity: High]
> Does this regression allow a malicious or buggy userspace to trigger this
> WARN_ON_ONCE and cause a host denial of service (especially with
> panic_on_warn=1)?

No, because panic_on_warn=1 isn't a DoS.  But yeah, the WARN is reachable, because
as Sashiko points out, the check on TD_STATE_INITIALIZED happens too late.  Given
that CPUID _can't_ be set yet, consuming per-vCPU information in __kvm_mmu_create()
is bizarre (it's a leftover from what APIs were available at the time).

I'm pretty sure we can sqaush the WARN and make the code more reasonable at the
same time by doing:

diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 611c78be8b41..d43b8b6c3b17 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -6837,7 +6837,7 @@ static int __kvm_mmu_create(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, struct k
 	 * other exception is for shadowing L1's 32-bit or PAE NPT on 64-bit
 	 * KVM; that horror is handled on-demand by mmu_alloc_special_roots().
 	 */
-	if (tdp_enabled && kvm_mmu_get_tdp_level(vcpu) > PT32E_ROOT_LEVEL)
+	if (tdp_enabled && kvm_mmu_get_max_tdp_level() > PT32E_ROOT_LEVEL)
 		return 0;
 
 	page = alloc_page(GFP_KERNEL_ACCOUNT | __GFP_DMA32);

> If userspace creates a TDX VM via KVM_CREATE_VM (setting the VM type to
> KVM_X86_TDX_VM) and then directly calls KVM_CREATE_VCPU without executing
> KVM_TDX_INIT_VM first, it appears this warning will be reached.
> 
> During vCPU creation, the MMU context is initialized unconditionally before
> the architecture-specific vCPU creation callback:
> 
> kvm_arch_vcpu_create()->kvm_mmu_create()->kvm_mmu_get_tdp_level()
> 
> Because KVM_TDX_INIT_VM was skipped, mirror_root_level remains 0, satisfying
> the condition and triggering the kernel warning.
> 
> The architecture-specific callback that enforces the TD_STATE_INITIALIZED
> requirement is invoked too late in the process to prevent this:
> 
> kvm_arch_vcpu_create()->kvm_x86_call(vcpu_create)()
> 
> Would it be safer to return an error or handle the uninitialized state rather
> than triggering a host-side warning on user-controllable input?
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260826215258.937210-1-seanjc@google.com?part=1