Re: [PATCH v6 21/21] KVM: s390: vsie: Enable use of VSIE SSCA

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The VSIE SSCA hardware interpretation (SIGPIF) feature is implicitly enabled based on host capabilities, bypassing guest capability negotiation and breaking live migration.
- [High] A TOCTOU race in `get_vsie_sca_unused` combined with an unhandled error path in `get_vsie_sca` causes KVM to return and dereference an ERR_PTR, leading to a host kernel panic.
--

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

KVM: s390: vsie: Enable use of VSIE SSCA

This commit enables code paths actually configuring and using VSIE SIGPI and
SRSI. This feature improves guest-3 performance by allowing hardware to handle
these instructions without exiting VSIE.

> diff --git a/arch/s390/kvm/s390/s390.c b/arch/s390/kvm/s390/s390.c
> index a1ce75be3955b..ffa5bbb8713bc 100644
> --- a/arch/s390/kvm/s390/s390.c
> +++ b/arch/s390/kvm/s390/s390.c
[ ... ]
> @@ -3363,7 +3367,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: High]
By enabling the SSCA feature globally based on the host capability here,
does this bypass guest capability negotiation?

In arch/s390/kvm/s390/vsie.c, use_ssca() checks the global kvm->arch.use_ssca
flag but appears to miss checking if the L1 guest actually negotiated the
KVM_S390_VM_CPU_FEAT_SIGPIF feature via test_kvm_cpu_feat().

Additionally, in shadow_scb_minimal():

    scb_s->eca |= scb_o->eca & ECA_SIGPI;
    scb_s->ecb |= scb_o->ecb & ECB_SRSI;

The requested features are copied into the shadow SCB without masking them
against the guest's negotiated capabilities. Could this allow a nested L1
guest to utilize hardware SSCA interpretation even if the VMM explicitly
disabled it, leading to silent live migration failures on destination hosts
without SSCA support?


[Severity: High]
Does enabling this feature expose a potential race condition and error pointer
dereference in the VSIE SCA handling?

In arch/s390/kvm/s390/vsie.c, if get_vsie_sca_unused() runs concurrently with
put_vsie_sca() (which decrements the refcount without holding vsie_sca_lock)
and all SCAs are temporarily busy, it can return ERR_PTR(-EAGAIN).

When get_vsie_sca() receives this error:

    if (IS_ERR(vsie_sca))
        goto out;

It jumps to the out label without updating the local rc variable. Since rc
remains 0 from a previous successful call to validate_scao(), get_vsie_sca()
incorrectly returns success while passing out the ERR_PTR.

This leads to kvm_s390_handle_vsie() seeing a success return:

    rc = get_vsie_sca(vcpu, scb_o, &vsie_sca);
    if (rc)
        goto out_unpin;
    rc = get_vsie_page_cpu_nr(vcpu, vsie_sca, ...);

And passing the invalid pointer to get_vsie_page_cpu_nr(), which immediately
dereferences it:

    vsie_page = vsie_sca->pages[cpu_nr];

Could this unhandled error path allow a nested guest workload to trigger a
host kernel panic?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827-vsie-sigpi-v6-0-8020bb53be52@linux.ibm.com?part=21