Re: [PATCH v4 20/20] KVM: s390: vsie: Enable use of VSIE SSCA

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Critical] Guest-2 can trigger an out-of-bounds array access (both read and write) in host kernel memory by supplying a malicious `icpua` value.
- [High] The newly introduced VSIE SCA shadowing code contains multiple WARN_ON_ONCE assertions that can be triggered by a malicious guest, leading to a host kernel panic.
- [High] VSIE unconditionally allows nested guests to use SSCA (SIGPI and SRSI interpretation) if the host supports it, bypassing the guest-2's negotiated CPU model capabilities.
- [High] Guest-triggerable QEMU/VM abort via invalid or unaligned SCA entry addresses.
--

--- Patch [20]: [PATCH v4 20/20] KVM: s390: vsie: Enable use of VSIE SSCA ---
commit 3bbd1f1a442d7f9a9ee468b6c61e02cb8392ba96
Author: Christoph Schlameuss <[email protected]>

KVM: s390: vsie: Enable use of VSIE SSCA

This commit enables code paths configuring and using VSIE SIGPI and SRSI.
It adds a new module parameter to globally disable SIGP, but defaults to
enabled on supported hardware to improve guest-3 performance.

> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index c21603f2745bf..59561d459a4f3 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c

[ ... ]

> @@ -477,6 +482,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_interp_extf && ssca)
> +		allow_cpu_feat(KVM_S390_VM_CPU_FEAT_SIGPIF);

[Severity: High]
Does this globally enable SSCA for the VM without verifying if the guest was
provisioned with the feature?

Looking at use_ssca() in arch/s390/kvm/vsie.c, it only checks the host-level
flag kvm->arch.use_ssca:

arch/s390/kvm/vsie.c:use_ssca() {
    if (!kvm->arch.use_ssca)
        return false;
    ...
}

Would this allow a nested guest to use SSCA features even if QEMU explicitly
disabled KVM_S390_VM_CPU_FEAT_SIGPIF for the CPU model, potentially breaking
capability negotiation and live migration?

[ ... ]

> @@ -3389,7 +3393,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>  
>  	kvm->arch.use_pfmfi = sclp.has_pfmfi;
>  	kvm->arch.use_skf = sclp.has_skey;
> -	kvm->arch.use_ssca = sclp.has_vsie_interp_extf;
> +	kvm->arch.use_ssca = sclp.has_vsie_interp_extf && ssca;

[Severity: Critical]
Is there a potential out-of-bounds array access when validating the guest's
icpua index now that these paths are being used?

In kvm_s390_handle_vsie(), the bounds check compares scb_o->icpua against
KVM_S390_MAX_VSIE_VCPUS:

arch/s390/kvm/vsie.c:kvm_s390_handle_vsie() {
    if (scb_o->icpua >= KVM_S390_MAX_VSIE_VCPUS) {
        rc = kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);
        goto out_unpin;
    }
    ...
}

Since icpua is a signed 16-bit integer, could a negative value bypass this
check?

Additionally, scb_o resides in guest memory. Is there a TOCTOU race where the
guest could change icpua after the check, before it is read again for the
array index in get_vsie_page_cpu_nr()?

arch/s390/kvm/vsie.c:get_vsie_page_cpu_nr() {
    ...
    vsie_page = vsie_sca->pages[cpu_nr];
    ...
    WRITE_ONCE(vsie_sca->pages[cpu_nr], vsie_page_new);
}

Could this lead to host memory corruption if an untrusted guest supplies a
malicious index?

[Severity: High]
Could enabling these code paths allow a guest to trigger host kernel panics
via WARN_ON_ONCE assertions?

For example, if a guest configures a nested guest with an unmapped SCA address,
pin_guest_pages() or pin_scb() would return a negative error code (like
-EFAULT). This error is assigned to sca_o_nr_pages and triggers a warning:

arch/s390/kvm/vsie.c:pin_sca() {
    ...
    if (WARN_ON_ONCE(vsie_sca->sca_o_nr_pages != nr_pages))
    ...
}

Similar warnings exist in get_vsie_page_cpu_nr() and get_vsie_page() when
vsie_page_init() fails. Since KVM guidelines advise against guest-reachable
WARN_ON assertions, should these be converted to avoid host Denial of Service?

[Severity: High]
Could this also allow a guest to crash the hypervisor by supplying invalid
nested SCB addresses?

In _shadow_sca(), if the guest provides an unaligned address, it returns
-EINVAL directly:

arch/s390/kvm/vsie.c:_shadow_sca() {
    if (scb_o_gpa & 0x1ffUL) {
        rc = -EINVAL;
        goto err;
    }
    ...
}

If the address is unmapped, get_vsie_page_cpu_nr() fails and returns -ENOMEM.
These error codes appear to propagate up to the main instruction intercept
handler. Will this cause KVM to exit to userspace with the error, aborting
the QEMU process instead of injecting an architectural program exception into
the guest?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=20