Re: [PATCH 06/21] KVM: s390: vsie: Add vsie_sigpif detection

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Truncation of host physical address in read_scao leads to use-after-free and memory leak.
- [High] Lost validity intercept during VSIE SCAO validation failure.
--

--- Patch [6]: [PATCH 06/21] KVM: s390: vsie: Add vsie_sigpif detection ---
commit 5159ce1359458442d26eeb7031f94445e04e2d6a
Author: Christoph Schlameuss <schlameuss@linux.ibm.com>

KVM: s390: vsie: Add vsie_sigpif detection

Add sensing of the VSIE Interpretation Extension Facility as vsie_sigpif
from SCLP. This facility is introduced with IBM Z gen17.

> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
> index eea24562e7db2..97581b748a94d 100644
> --- a/arch/s390/kvm/vsie.c
> +++ b/arch/s390/kvm/vsie.c
> @@ -72,6 +72,27 @@ struct vsie_page {
>  
>  static_assert(sizeof(struct vsie_page) == PAGE_SIZE);
>  
> +static inline bool sie_uses_esca(struct kvm_s390_sie_block *scb)
> +{
> +	return (scb->ecb2 & ECB2_ESCA);
> +}
> +
> +static unsigned long read_scao(struct kvm *kvm, struct kvm_s390_sie_block *scb)
> +{
> +	unsigned long vsie_sca = READ_ONCE(scb->scaol) & ~0xfUL;
> +
> +	if (test_kvm_cpu_feat(kvm, KVM_S390_VM_CPU_FEAT_64BSCAO))
> +		vsie_sca |= (u64)READ_ONCE(scb->scaoh) << 32;

[Severity: Critical]
Does this code truncate the host physical address if the guest lacks the
KVM_S390_VM_CPU_FEAT_64BSCAO feature?

When read_scao() is called from unpin_blocks() on the shadow SCB (scb_s):

arch/s390/kvm/vsie.c:unpin_blocks() {
    ...
    hpa = read_scao(vcpu->kvm, scb_s);
    if (hpa) {
        unpin_guest_page(vcpu->kvm, vsie_page->sca_gpa, hpa);
    ...
}

The shadow SCB contains a 64-bit host physical address. If the L1 guest is
configured without the 64BSCAO feature, read_scao() will silently drop the
upper 32 bits of the HPA.

Could this truncated address then be passed to unpin_guest_page(),
causing it to unpin the wrong host physical page (use-after-free) while
leaking the actually pinned page?

> +
> +	return vsie_sca;
> +}
> +
> +static void write_scao(struct kvm_s390_sie_block *scb, unsigned long hpa)
> +{
> +	scb->scaoh = (u32)((u64)hpa >> 32);
> +	scb->scaol = (u32)(u64)hpa;
> +}
> +
>  /* trigger a validity icpt for the given scb */
>  static int set_validity_icpt(struct kvm_s390_sie_block *scb,
>  			     __u16 reason_code)
> @@ -82,6 +103,25 @@ static int set_validity_icpt(struct kvm_s390_sie_block *scb,
>  	return 1;
>  }
>  
> +/* The sca header must not cross pages etc. */
> +static int validate_scao(struct kvm_vcpu *vcpu, struct kvm_s390_sie_block *scb, gpa_t gpa)
> +{
> +	int offset;
> +
> +	if (gpa < 2 * PAGE_SIZE)
> +		return set_validity_icpt(scb, 0x0038U);

[Severity: High]
Can this validity intercept be lost during VSIE SCAO validation failure?

Looking at pin_blocks(), it calls validate_scao() and passes the guest
SCB (scb_o):

arch/s390/kvm/vsie.c:pin_blocks() {
    ...
    rc = validate_scao(vcpu, scb_o, gpa);
    if (rc)
        goto unpin;
    ...
}

When validate_scao() fails, it injects the intercept code into scb_o.
However, on the failure path, unshadow_scb() is called:

arch/s390/kvm/vsie.c:unshadow_scb() {
    ...
    scb_o->icptcode = scb_s->icptcode;
    scb_o->icptstatus = scb_s->icptstatus;
    scb_o->ipa = scb_s->ipa;
    scb_o->ipb = scb_s->ipb;
    ...
}

Would unshadow_scb() unconditionally overwrite scb_o's intercept fields
with those from the shadow SCB (scb_s), erasing the validity intercept
that was just written to scb_o?

Could this result in the L1 guest receiving an architecturally invalid
exit without an intercept code?

> +	if ((gpa & ~0x1fffUL) == kvm_s390_get_prefix(vcpu))
> +		return set_validity_icpt(scb, 0x0011U);
> +
> +	if (sie_uses_esca(scb))
> +		offset = offsetof(struct esca_block, cpu[0]) - 1;
> +	else
> +		offset = offsetof(struct bsca_block, cpu[0]) - 1;
> +	if ((gpa & PAGE_MASK) != ((gpa + offset) & PAGE_MASK))
> +		return set_validity_icpt(scb, 0x003bU);
> +	return 0;
> +}
> +

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