Re: [PATCH v4 07/11] KVM: guest_memfd: Add support for freezing mappings

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Holding the global `kvm_gmem_freeze_srcu` read lock during unbounded `fallocate` operations allows an unprivileged tenant to block `kvm_gmem_freeze()` indefinitely for other VMs.
--

--- Patch [7]: [PATCH v4 07/11] KVM: guest_memfd: Add support for freezing mappings ---
commit de8f141a41c06197ca510e03554977beeeb4fcdf
Author: Tarun Sahu <tarunsahu@google.com>

KVM: guest_memfd: Add support for freezing mappings

This commit introduces kvm_gmem_freeze() to freeze a guest_memfd inode's
mapping to prevent fallocate and page fault allocations during preservation.
It uses a global SRCU to synchronize freeze state checkers without incurring
per-fault locking overhead or per-CPU memory exhaustion.

> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index fe1adc9ba48d1..a4d9d348e4d16 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
[ ... ]
> @@ -273,16 +284,30 @@ static long kvm_gmem_allocate(struct inode *inode, loff_t offset, loff_t len)
>  static long kvm_gmem_fallocate(struct file *file, int mode, loff_t offset,
>  			       loff_t len)
>  {
> +	struct inode *inode = file_inode(file);
>  	int ret;
> +	int idx;
>  
> -	if (!(mode & FALLOC_FL_KEEP_SIZE))
> -		return -EOPNOTSUPP;
> +	idx = srcu_read_lock(&kvm_gmem_freeze_srcu);
> +	if (kvm_gmem_is_frozen(inode)) {
> +		srcu_read_unlock(&kvm_gmem_freeze_srcu, idx);
> +		return -EPERM;
> +	}
[ ... ]
>  	if (mode & FALLOC_FL_PUNCH_HOLE)
>  		ret = kvm_gmem_punch_hole(file_inode(file), offset, len);
>  	else
>  		ret = kvm_gmem_allocate(file_inode(file), offset, len);
>  
>  	if (!ret)
>  		file_modified(file);
> +
> +out:
> +	srcu_read_unlock(&kvm_gmem_freeze_srcu, idx);
>  	return ret;
>  }

[Severity: High]
Does this code allow an unprivileged tenant to stall the system by holding the
global kvm_gmem_freeze_srcu read lock across unbounded fallocate operations?

If a tenant requests a massive hole punch or allocation, kvm_gmem_fallocate()
holds the read lock for the entire duration of kvm_gmem_punch_hole() or
kvm_gmem_allocate().

If another VM triggers kvm_gmem_freeze(..., true) during this time, it will
block in synchronize_srcu(&kvm_gmem_freeze_srcu) until the massive operation
completes.

Could this lead to a cross-tenant denial of service where one VM blocks live
updates and preservation operations for all other VMs on the same hypervisor?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728121138.1103610-1-tarunsahu@google.com?part=7