Re: [PATCH v6 06/43] KVM: x86/mmu: Bug the VM if gmem attributes are queried to determine max mapping level

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The newly added KVM_BUG_ON check in kvm_mmu_max_mapping_level evaluates global state and unconditionally crashes standard, non-confidential VMs whenever user-space disables dirty logging.
- [Low] The patch unconditionally references conditionally compiled symbols (`__kvm_get_memory_attributes` and `kvm_gmem_get_memory_attributes`), resulting in build and link failures on standard configurations.
--

commit ffa430675edb844f07837310c0934745f310bf26
Author: Ackerley Tng <ackerleytng@google.com>

KVM: x86/mmu: Bug the VM if gmem attributes are queried to determine max mapping level

This commit introduces a KVM_BUG_ON check in kvm_mmu_max_mapping_level()
to prevent querying guest_memfd memory attributes while holding the MMU
lock.

> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index a80a876ab4ad6..153bcc5369985 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
[ ... ]
> @@ -3357,6 +3357,15 @@ int kvm_mmu_max_mapping_level(struct kvm *kvm, struct kvm_page_fault *fault,
>  		max_level = fault->max_level;
>  		is_private = fault->is_private;
>  	} else {
> +		/*
> +		 * Memory attributes cannot be obtained from guest_memfd while
> +		 * the MMU lock is held.
> +		 */
> +		if (KVM_BUG_ON(static_call_query(__kvm_get_memory_attributes) ==
> +			       kvm_gmem_get_memory_attributes, kvm)) {

[Severity: Low]
Does this code cause build and link failures on standard configurations?

When CONFIG_KVM_MEMORY_ATTRIBUTES is disabled (e.g. standard x86 builds
without confidential VM features), __kvm_get_memory_attributes is not
declared.

Additionally, on 32-bit builds where CONFIG_KVM_GUEST_MEMFD is disabled,
kvm_gmem_get_memory_attributes is undefined. Unconditionally referencing
these symbols here breaks the build on those setups.

[Severity: High]
Does this check evaluate global state instead of checking if the specific
memslot uses guest_memfd, potentially crashing standard VMs?

On standard x86_64 configurations, KVM initialization can set this global
static call to kvm_gmem_get_memory_attributes for all VMs. If userspace
(like QEMU) disables dirty logging on any memslot, KVM triggers huge page
recovery:

kvm_tdp_mmu_recover_huge_pages()
    kvm_mmu_max_mapping_level(..., fault = NULL, ...)

Since fault is NULL, this executes the KVM_BUG_ON() check. Because the
global static call matches, the condition evaluates to true and immediately
kills the innocent VM via kvm_vm_bugged().

Could an unprivileged userspace VMM trigger a local denial of service
simply by toggling dirty logging on standard non-confidential VMs?

> +			return 0;
> +		}
> +
>  		max_level = PG_LEVEL_NUM;
>  		is_private = kvm_mem_is_private(kvm, gfn);
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260507-gmem-inplace-conversion-v6-0-91ab5a8b19a4@google.com?part=6