Re: [PATCH v2 25/28] KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] kvm: mixed-attribute hugepage mapping via race when mmu_lock is dropped
- [High] kvm: soft lockup in kvm_arch_post_set_memory_attributes() due to unbounded loop
--

commit 33f579fe7310efff8ad87a283b4a1e970511e847
Author: Paolo Bonzini <pbonzini@redhat.com>
Subject: KVM: x86/mmu: Obsolete all roots if memattr contains gPTEs

This commit introduces a mechanism to invalidate all MMU roots when applying
memory protection attributes against a GPTE page. It splits the fast zap
operation into a locked front-half and an unlocked back-half.

> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 097095f71d605..d658cfe31cd9b 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
[ ... ]
> @@ -8320,9 +8321,40 @@ bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
>  				hugepage_set_mixed(slot, gfn, level);
>  		}
>  	}
> +
> +	/*
> +	 * There are special considerations when applying an memory protection
> +	 * attibute against a GPTE page. If set read-only, access/dirty bits
> +	 * within that page shouldn't be updated. If set non-accesible,
> +	 * accessing a virtual address that requires traversing that GPTE page
> +	 * should fault.
> +	 *
> +	 * On TDP enabled guests, the CPU faults on the GPTE address upon
> +	 * detecting such a situation.
> +	 *
> +	 * On non-TDP, upon detecting this situation, and based on the fact it
> +	 * should be a rare occasion, invalidate all the mmu roots.
> +	 */
> +	for (gfn_t gfn = range->start; gfn < range->end; gfn++) {

[Severity: High]
Could this loop cause a host soft lockup and RCU stalls?

If host userspace issues a KVM_SET_MEMORY_ATTRIBUTES ioctl with a massive
memory range, this loop will iterate over the entire guest-controlled GFN
range.

Because it executes hash table lookups via for_each_gfn_valid_sp_with_gptes()
while holding mmu_lock for write without any cond_resched(), could a
malicious guest or VMM orchestrate massive memslot updates to degrade host
availability?

> +		for_each_gfn_valid_sp_with_gptes(kvm, sp, gfn) {
> +			__kvm_mmu_zap_all_fast_front_half(kvm);

[Severity: Critical]
Can this lead to memory isolation breakage by allowing mixed-attribute
hugepage mappings?

During kvm_vm_set_mem_attributes(), kvm_handle_gfn_range() is called with
post_set_range. When processing the first memslot, it triggers range->on_lock,
which maps to kvm_mmu_invalidate_end() and sets mmu_invalidate_in_progress
to 0.

When __kvm_mmu_zap_all_fast_front_half() is called here, it can drop and
reacquire mmu_lock via cond_resched_rwlock_write().

While the lock is dropped and mmu_invalidate_in_progress is 0, could a
concurrent page fault on a subsequent memslot proceed? If that memslot's
disallow_lpage flag hasn't been updated yet, KVM might map a hugepage using
the specific faulted GFN's attributes, bypassing the mixed attributes in the
xarray entirely.

> +			return false;
> +		}
> +	}
>  	return false;
>  }

[ ... ]

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