Re: [PATCH v5 18/21] KVM: s390: vsie: Add VSIE max shadow configuration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unbounded memory leak of XArray nodes in `addr_to_page` due to missing `xa_erase` when reusing a `vsie_page`.
--

commit aeb8317597460836fd64fcf59420cb809c866f05
Author: Christoph Schlameuss <schlameuss@linux.ibm.com>

KVM: s390: vsie: Add VSIE max shadow configuration

Introduce two new module parameters allowing to keep more shadow
structures

[ ... ]

> diff --git a/arch/s390/kvm/s390/vsie.c b/arch/s390/kvm/s390/vsie.c
> index 6e42b00206bd9..fe94587511b03 100644
> --- a/arch/s390/kvm/s390/vsie.c
> +++ b/arch/s390/kvm/s390/vsie.c

[ ... ]

> @@ -1962,7 +1973,8 @@ static struct vsie_page *get_vsie_page(struct kvm_vcpu *vcpu, unsigned long addr
>  		put_vsie_page(vsie_page);
>  	}
>  
> -	max_vsie_page = atomic_read(&kvm->online_vcpus);
> +	max_vsie_page = min_t(unsigned int, max_t(unsigned int, atomic_read(&kvm->online_vcpus),
> +			      vsie_shadow_scb_max), KVM_S390_MAX_VSIE_VCPUS);
>  
>  	/* allocate new vsie_page - we will likely need it */
>  	if (kvm->arch.vsie.page_count < max_vsie_page) {

[Severity: High]
This is a pre-existing issue, but does reusing a vsie_page here lead to an
unbounded memory leak of XArray nodes in addr_to_page?

When the vsie_page pool reaches max_vsie_page, get_vsie_page() recycles an
existing vsie_page:

arch/s390/kvm/s390/vsie.c:get_vsie_page() {
    ...
	} else {
		/* reuse an existing entry that belongs to nobody */
		while (true) {
			pages_idx = kvm->arch.vsie.next;
			kvm->arch.vsie.next++;
			kvm->arch.vsie.next %= kvm->arch.vsie.page_count;
			vsie_page = kvm->arch.vsie.pages[pages_idx];
			if (try_get_vsie_page(vsie_page))
				break;
		}

		unpin_scb(kvm, vsie_page);
		kvm->stat.vsie_shadow_scb_reuse++;
	}

	rc = init_vsie_page(vcpu, vsie_page, addr);
	if (!rc)
		xa_store(&kvm->arch.vsie.addr_to_page, addr >> SCB_ALIGNMENT_SHIFT, vsie_page,
			 GFP_KERNEL_ACCOUNT);
    ...
}

Should xa_erase() be called for the old index (vsie_page->scb_gpa >>
SCB_ALIGNMENT_SHIFT) before the vsie_page is repurposed?

If a nested guest repeatedly executes the SIE instruction with continuously
varying scb_addr values, the new address is stored in the XArray via
xa_store(), but the old index appears to never be removed.

Since XArray internally allocates memory for nodes as new indices are
inserted, can a malicious guest intentionally trigger unbounded allocation
of XArray nodes, leading to host or cgroup OOM?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826-vsie-sigpi-v5-0-cf471edb46b2@linux.ibm.com?part=18