Re: [PATCH 5.15.y 8/8] KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The patch accidentally removes the `!kvm_is_reserved_pfn(pfn)` check while adding the `is_gfn_in_memslot(slot, sp->gfn)` bounds check. This allows reserved PFNs (e.g., from VM_PFNMAP device memory mappings) to be processed for hugepage collapsing, resulting in a host kernel panic.
--

commit 2d19b4db9edc2ca668a2a822466a8d07744d71f3
Author: Sean Christopherson <seanjc@google.com>

KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level

This patch adds a bounds check in the shadow MMU to verify the base gfn of
a shadow page is within the target memslot before querying the max mapping
level. This prevents out-of-bounds access to the slot's lpage_info when
guest hugepage mappings extend below the bounds of a memslot.

> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index e9dbe3e7ec622..9a3020648c8be 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
[ ... ]
> @@ -5883,13 +5883,19 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm,
[ ... ]
> -		if (sp->role.direct && !kvm_is_reserved_pfn(pfn) &&
> +		if (sp->role.direct && is_gfn_in_memslot(slot, sp->gfn) &&
>  		    sp->role.level < kvm_mmu_max_mapping_level(kvm, slot, sp->gfn,
>  							       pfn, PG_LEVEL_NUM)) {

[Severity: Critical]
Does this code accidentally drop the check for reserved PFNs?

If a memslot maps device memory (VM_PFNMAP), the SPTE contains a reserved
PFN with no backing struct page. Since the !kvm_is_reserved_pfn(pfn) check
was removed, this loop can now pass these reserved PFNs down into
kvm_mmu_max_mapping_level(), which takes the following path:

kvm_mmu_zap_collapsible_spte()
  kvm_mmu_max_mapping_level()
    host_pfn_mapping_level()

Inside host_pfn_mapping_level(), the code executes:

    if (!PageCompound(pfn_to_page(pfn)) && !kvm_is_zone_device_pfn(pfn))

Could calling pfn_to_page() on a reserved PFN here result in dereferencing
an unmapped vmemmap pointer, causing a host kernel panic?

>  			pte_list_remove(kvm, rmap_head, sptep);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626112606.1778248-1-pbonzini@redhat.com?part=8