Re: [PATCH] KVM: x86/mmu: Don't create SPTEs for addresses that aren't mappable

[Sean Christopherson]

On Thu, Mar 05, 2026, Yan Zhao wrote:
> On Wed, Feb 18, 2026 at 04:22:41PM -0800, Sean Christopherson wrote:
> > Track the mask of guest physical address bits that can actually be mapped
> > by a given MMU instance that utilizes TDP, and either exit to userspace
> > with -EFAULT or go straight to emulation without creating an SPTE (for
> > emulated MMIO) if KVM can't map the address.  Attempting to create an SPTE
> > can cause KVM to drop the unmappable bits, and thus install a bad SPTE.
> > E.g. when starting a walk, the TDP MMU will round the GFN based on the
> > root level, and drop the upper bits.
> > 
> > Exit with -EFAULT in the unlikely scenario userspace is misbehaving and
> > created a memslot that can't be addressed, e.g. if userspace installed
> > memory above the guest.MAXPHYADDR defined in CPUID, as there's nothing KVM
> > can do to make forward progress, and there _is_ a memslot for the address.
> > For emulated MMIO, KVM can at least kick the bad address out to userspace
> > via a normal MMIO exit.
> > 
> > The flaw has existed for a very long time, and was exposed by commit
> > 988da7820206 ("KVM: x86/tdp_mmu: WARN if PFN changes for spurious faults")
> > thanks to a syzkaller program that prefaults memory at GPA 0x1000000000000
> > and then faults in memory at GPA 0x0 (the extra-large GPA gets wrapped to
> > '0').
> If the scenario is: when ad bit is disabled, prefault memory at GPA 0x0, then
> guest reads memory at GPA 0x1000000000000, would fast_page_fault() fix a wrong
> wrapped sptep for GPA 0x1000000000000?
> 
> Do we need to check fault->addr in fast_page_fault() as well?

Ugh, yeah, good catch!