Re: [PATCH 21/21] KVM: s390: vsie: Enable VSIE SIGPI

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] The guest-controlled `icpua` field is used as an array index into `vsie_sca->pages` without bounds checking, allowing an attacker to corrupt arbitrary host kernel memory.
- [High] A guest can permanently leak vsie_sca structures by providing an invalid SCAO, eventually exhausting the vsie_sca pool and breaking nested virtualization.
- [High] A malicious guest can intentionally trigger host kernel warnings (WARN_ON_ONCE) by supplying unmapped guest physical addresses in the System Control Area (SCA) structures.
--

--- Patch [21]: [PATCH 21/21] KVM: s390: vsie: Enable VSIE SIGPI ---
commit ea08ed257ee1485d9e9b61914b578f7cc9773f7a
Author: Christoph Schlameuss <schlameuss@linux.ibm.com>

KVM: s390: vsie: Enable VSIE SIGPI
    
Finally enable code paths actually configuring and using VSIE SIGPI.
SIGP can be globally disabled in the KVM module configuration but will
be enabled by default if the machine (IBM z16 onwards) supports it.

> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 481e566fe228b..854de405d08c7 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
[ ... ]
> @@ -476,6 +481,8 @@ static void __init kvm_s390_cpu_feat_init(void)
>  		allow_cpu_feat(KVM_S390_VM_CPU_FEAT_KSS);
>  	if (sclp.has_astfleie2)
>  		allow_cpu_feat(KVM_S390_VM_CPU_FEAT_ASTFLEIE2);
> +	if (sclp.has_vsie_sigpif && vsie_sigpi)
> +		allow_cpu_feat(KVM_S390_VM_CPU_FEAT_SIGPIF);

[Severity: High]
Does enabling this feature expose a resource leak when providing an invalid
SCAO address?

Looking at get_vsie_sca() in arch/s390/kvm/vsie.c, if a guest provides an
unmapped SCAO address, pin_sca() fails and returns an error:

arch/s390/kvm/vsie.c:get_vsie_sca() {
    ...
	rc = pin_sca(kvm, vsie_sca);
	if (rc) {
		vsie_sca = ERR_PTR(rc);
		goto out;
	}
    ...
}

It appears the newly added vsie_sca object is left in the kvm->arch.vsie.scas
array with an undecremented ref_count, permanently leaking it from the
reusable pool.

[Severity: High]
Can a guest intentionally trigger host kernel warnings by supplying unmapped
guest physical addresses in the System Control Area structures?

When a guest provides an unbacked SCA address, pin_guest_pages() in pin_sca()
returns -EFAULT, which directly triggers the host WARN_ON_ONCE:

arch/s390/kvm/vsie.c:pin_sca() {
    ...
	vsie_sca->sca_o_nr_pages = pin_guest_pages(kvm, vsie_sca->sca_gpa, nr_pages,
						   vsie_sca->sca_o_pages);
	if (WARN_ON_ONCE(vsie_sca->sca_o_nr_pages != nr_pages))
		return -EIO;
    ...
}

Similarly, in get_vsie_page_cpu_nr(), if the SCB address is unmapped,
vsie_page_init() returns -ENOMEM and also triggers a WARN_ON_ONCE:

arch/s390/kvm/vsie.c:get_vsie_page_cpu_nr() {
    ...
		scoped_guard(mutex, &vcpu->kvm->arch.vsie.mutex) {
			unpin_scb(vcpu->kvm, vsie_page);
			rc = vsie_page_init(vcpu, vsie_page, scb_gpa);
		}
		if (WARN_ON_ONCE(rc)) {
    ...
}

[Severity: Critical]
Does this enablement allow an out-of-bounds array access in
get_vsie_page_cpu_nr()?

In get_vsie_page_cpu_nr(), the guest-controlled cpu_nr (which comes from
icpua and can be up to 65535) is used as an index to read from and write to
the pages array, which is only sized to 256:

arch/s390/kvm/vsie.c:get_vsie_page_cpu_nr() {
    ...
	vsie_page = vsie_sca->pages[cpu_nr];
	if (!vsie_page) {
		vsie_page_new = alloc_vsie_page(vcpu->kvm);
		...
		scoped_guard(mutex, &vsie_sca->mutex) {
			vsie_page = vsie_sca->pages[cpu_nr];
			if (!vsie_page) {
				WRITE_ONCE(vsie_sca->pages[cpu_nr], vsie_page_new);
    ...
}

Could this corrupt adjacent host kernel memory structures?

>  	/*
>  	 * KVM_S390_VM_CPU_FEAT_SKEY: Wrong shadow of PTE.I bits will make
>  	 * all skey handling functions read/set the skey from the PGSTE

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-vsie-sigpi-v1-0-ea9f12066408@linux.ibm.com?part=21