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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] get_vsie_page_cpu_nr() erroneously wraps a positive return code (1) in ERR_PTR(), bypassing IS_ERR() checks and causing a host kernel panic.
- [High] VSIE SIGPI interpretation feature is globally enabled, bypassing KVM CPU feature negotiation and leaking the feature to nested guests.
- [High] get_vsie_sca() propagates validation and pinning errors as ERR_PTR(-EINVAL), crashing the VM instead of injecting an intercept.
--

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

KVM: s390: vsie: Enable use of VSIE SSCA

This commit enables the use of VSIE SSCA code paths for handling SIGPI
and SRSI instructions without exiting VSIE. The feature defaults to true
on supported hardware.

> 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]
Does this bypass KVM CPU feature negotiation and leak the SSCA feature to
nested guests?

When ssca is enabled here, use_ssca() in arch/s390/kvm/s390/vsie.c relies
purely on kvm->arch.use_ssca:

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

The hardware intercept bits are then unconditionally copied to the shadow SCB
without validating the guest's CPU feature model:

arch/s390/kvm/s390/vsie.c:prepare_scb() {
...
	if (vsie_page->vsie_sca) {
		scb_s->eca |= scb_o->eca & ECA_SIGPI;
		scb_s->ecb |= scb_o->ecb & ECB_SRSI;
...
}

Could this break live migration by exposing hardware features to the guest
without QEMU explicitly opting in via the KVM_S390_VM_CPU_FEAT_SIGPIF CPU
feature?

[Severity: Critical]
Does enabling this feature expose a host kernel panic when handling invalid
SCB addresses?

Enabling use_ssca routes execution to get_vsie_page_cpu_nr() in
kvm_s390_handle_vsie(). If an L1 guest provides an invalid SCB address,
init_vsie_page() injects a program interrupt and returns 1. However,
get_vsie_page_cpu_nr() wraps this positive return code in ERR_PTR:

arch/s390/kvm/s390/vsie.c:get_vsie_page_cpu_nr() {
...
	rc = init_vsie_page(vcpu, vsie_page_new, scb_gpa);
	if (rc) {
		put_vsie_page(vsie_page);
		return ERR_PTR(rc);
	}
...
}

The caller then checks IS_ERR(vsie_page), which evaluates to false for a
positive value like (void*)1:

arch/s390/kvm/s390/vsie.c:kvm_s390_handle_vsie() {
...
		vsie_page = get_vsie_page_cpu_nr(vcpu, vsie_sca, scb_addr,
						 scb_o->icpua & KVM_S390_CPU_MASK);
		if (IS_ERR(vsie_page)) {
			rc = PTR_ERR(vsie_page);
...
}

Will this allow execution to proceed and dereference the invalid pointer,
leading to a full host denial of service?

[Severity: High]
Can an invalid SCA origin provided by an L1 guest cause a complete VM abort?

Similar to the regression above, the newly reachable get_vsie_sca()
converts the return code 1 from validate_scao() into a hard -EINVAL error:

arch/s390/kvm/s390/vsie.c:get_vsie_sca() {
...
	rc = validate_scao(vcpu, scb_o, sca_gpa);
	if (rc)
		return ERR_PTR(-EINVAL);
...
}

It also propagates pinning errors directly as hard errors rather than
injecting intercepts:

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

These errors are propagated all the way up to kvm_arch_vcpu_ioctl_run(),
which returns -EINVAL to QEMU and aborts the entire VM. Is it
intended to crash the VM instead of gracefully resuming the guest with an
intercept when a misaligned or unmapped SCAO is encountered?

>  	spin_lock_init(&kvm->arch.start_stop_lock);
>  	kvm_s390_vsie_init(kvm);
>  	if (use_gisa)

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