Re: [PATCH v3 1/2] KVM: Bound per-VM GFN materialization in KVM_SET_MEMORY_ATTRIBUTES

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Conservative quota bound check over-accounts overlapping requests and restricts maximum VM memory to 128 GiB.
--

commit 458d355532cc6dd4b9524cc1a387ddd8644cc6f6
Author: David Ballesteros <davimaba.v@proton.me>

KVM: Bound per-VM GFN materialization in KVM_SET_MEMORY_ATTRIBUTES

This commit adds a bound to the number of GFNs that can be materialized
in the memory attributes xarray. This ensures unprivileged users cannot
exhaust host memory when creating private memory VMs.

> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 3dd04605f2e55..bb03dc20d3f98 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
[ ... ]
> @@ -573,6 +573,13 @@ static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
>   * This number must be determined not to exceed such limits.
>   */
>  #define KVM_MEM_MAX_NR_PAGES ((1UL << 31) - 1)
> +/*
> + * Hardening bound: maximum number of GFNs with a materialized entry in
> + * mem_attr_array per VM (~300 MiB of xa_nodes at 2^25).  Without it,
> + * KVM_SET_MEMORY_ATTRIBUTES grows the array without limit (~9.3 bytes of
> + * kernel memory per GFN) on GFNs with no backing memory.
> + */
> +#define KVM_MEM_ATTR_MAX_GFNS	(1UL << 25)

[ ... ]
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 108d42c5c1d6a..c0696bd88461a 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
[ ... ]
> @@ -2579,14 +2602,67 @@ static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
[ ... ]
> +	/*
> +	 * Bound the number of materialized GFNs per VM.  See the comment on
> +	 * KVM_MEM_ATTR_MAX_GFNS.
> +	 */
> +	if (kvm->mem_attr_gfn_count + (end - start) > KVM_MEM_ATTR_MAX_GFNS) {
> +		r = -ENOSPC;
> +		goto out_unlock;
> +	}

[Severity: High]
Does this boundary check over-account for overlapping requests?

If a VM issues a request over a large range that overlaps with mostly 
populated entries, this check assumes every GFN in the range is a new entry 
by adding end - start to the current count.

Could this cause valid requests on large VMs (e.g. bulk memory attribute
updates during a reboot) to fail with a spurious -ENOSPC, effectively 
preventing operations even when the actual number of new entries being 
added would remain well under the limit?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911221302.53013-1-davimaba.v@proton.me?part=1