Re: [PATCH v5 20/21] KVM: s390: vsie: Create minimal scb shadows for not running g3 blocks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Hardware SIGPI execution can read a partially zeroed `scb_s` structure while KVM is executing `memset` on it, leading to host memory corruption via wild physical address writes.
--

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

KVM: s390: vsie: Create minimal scb shadows for not running g3 blocks

This commit introduces a minimal shadow of the vSIE control block for
guest-3 blocks that are not currently running. The minimal shadow only
contains the information needed for SIGPI and SRSI and is recreated fully
when a vSIE is entered with that SCB later.

[ ... ]

> diff --git a/arch/s390/kvm/s390/vsie.c b/arch/s390/kvm/s390/vsie.c
> index 335ed1a927aa6..86ccd92233b5c 100644
> --- a/arch/s390/kvm/s390/vsie.c
> +++ b/arch/s390/kvm/s390/vsie.c

[ ... ]

> @@ -2166,7 +2186,7 @@ static int _shadow_sca_cpu(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page,
>  	if (IS_ERR(vsie_page_n))
>  		return PTR_ERR(vsie_page_n);
>  
> -	rc = shadow_scb(vcpu, vsie_page_n);
> +	rc = shadow_scb_minimal(vcpu, vsie_page_n);

[Severity: Critical]
Can this lead to host memory corruption if a malicious guest-2 changes the
SDA (scb_gpa) for a nested vCPU in its SCA while another guest-2 vCPU is
actively running sie for the same VM?

When guest-2 enters sie for the modified vCPU, KVM's get_vsie_page_cpu_nr()
call just above this block unpins the old SCB and clears the shadow SCB:

arch/s390/kvm/s390/vsie.c:reset_vsie_page() {
    ...
    memset(&vsie_page->scb_s, 0, sizeof(struct kvm_s390_sie_block));
    ...
}

Does this memset execute while the other hardware thread is actively allowed
to follow the ssda pointer to it?

If osda is zeroed while hardware SIGPI execution reads this partially
zeroed scb_s structure, it appears hardware could write to absolute
physical address 0 (or a freed host page), causing host memory corruption.

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