From: sashiko-bot@kernel.org
To: "Claudio Imbrenda" <imbrenda@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH v3 06/10] KVM: s390: Fix overclearing ESCA in case of error
Date: Mon, 27 Jul 2026 16:33:28 +0000 [thread overview]
Message-ID: <20260727163329.3996E1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260727150254.236021-7-imbrenda@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] For UCONTROL VMs, the ESCA block CPU array is accessed out of bounds because vCPU IDs up to 254 are permitted, exceeding the array's size of 248.
--
--- Patch [6]: [PATCH v3 06/10] KVM: s390: Fix overclearing ESCA in case of error ---
commit 711c5a0b8c8ac3214d997bede21c76e30e58d712
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
KVM: s390: Fix overclearing ESCA in case of error
This commit modifies vCPU destruction to skip clearing the ESCA entry if
the vCPU was not successfully initialized.
> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> index 9e3e6b0d72ad6..2acdff130fa6c 100644
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
> @@ -86,7 +86,7 @@ static void sca_clear_ext_call(struct kvm_vcpu *vcpu)
> struct esca_block *sca = vcpu->kvm->arch.sca;
> union esca_sigp_ctrl *sigp_ctrl = &sca->cpu[vcpu->vcpu_id].sigp_ctrl;
>
> - if (!kvm_s390_use_sca_entries())
> + if (!kvm_s390_use_sca_entries() || !vcpu->arch.initialized)
> return;
> kvm_s390_clear_cpuflags(vcpu, CPUSTAT_ECALL_PEND);
>
> WRITE_ONCE(sigp_ctrl->value, 0);
[Severity: High]
This is a pre-existing issue, but does this code write past the bounds of
the esca_block allocation for UCONTROL VMs?
Looking at kvm_arch_vcpu_precreate() in arch/s390/kvm/kvm-s390.c, the
bounds check for ESCA CPU slots is explicitly bypassed for UCONTROL VMs:
if (!kvm_is_ucontrol(kvm) && !sca_can_add_vcpu(kvm, id))
return -EINVAL;
This allows vCPU IDs up to 254. However, the ESCA block CPU array only has
248 slots, and the block itself is allocated as exactly 4 pages.
When destroying a vCPU with an ID >= 248, the write operation in this
function appears to access memory past the end of the esca_block.
A similar situation seems to happen in sca_inject_ext_call() when
processing external calls:
arch/s390/kvm/interrupt.c:sca_inject_ext_call() {
...
union esca_sigp_ctrl *sigp_ctrl = &sca->cpu[vcpu->vcpu_id].sigp_ctrl;
...
rc = cmpxchg(&sigp_ctrl->value, old_val.value, new_val.value);
...
}
Could this lead to kernel memory corruption if a UCONTROL VM is created
with large vCPU IDs?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260727150254.236021-1-imbrenda@linux.ibm.com?part=6
next prev parent reply other threads:[~2026-07-27 16:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 15:02 [PATCH v3 00/10] KVM: s390: Misc fixes Claudio Imbrenda
2026-07-27 15:02 ` [PATCH v3 01/10] KVM: s390: Fix unlikely NULL gmap dereference Claudio Imbrenda
2026-07-27 15:24 ` sashiko-bot
2026-07-27 15:02 ` [PATCH v3 02/10] KVM: s390: Fix leaking of PGM_ADDRESSING to userspace Claudio Imbrenda
2026-07-27 15:33 ` sashiko-bot
2026-07-27 15:02 ` [PATCH v3 03/10] KVM: s390: Fix race in __do_essa() Claudio Imbrenda
2026-07-27 15:43 ` sashiko-bot
2026-07-27 15:02 ` [PATCH v3 04/10] KVM: s390: cmma: Fix dirty tracking when removing memslot Claudio Imbrenda
2026-07-27 16:03 ` sashiko-bot
2026-07-27 15:02 ` [PATCH v3 05/10] KVM: s390: ucontrol: Add missing locking around gmap_remove_child() Claudio Imbrenda
2026-07-27 16:14 ` sashiko-bot
2026-07-27 15:02 ` [PATCH v3 06/10] KVM: s390: Fix overclearing ESCA in case of error Claudio Imbrenda
2026-07-27 16:33 ` sashiko-bot [this message]
2026-07-27 15:02 ` [PATCH v3 07/10] KVM: s390: Return -EINTR if a signal was pending while faulting-in Claudio Imbrenda
2026-07-27 16:59 ` sashiko-bot
2026-07-27 15:02 ` [PATCH v3 08/10] KVM: s390: Free the mmu cache when kvm_arch_vcpu_create() fails Claudio Imbrenda
2026-07-27 17:06 ` sashiko-bot
2026-07-27 15:02 ` [PATCH v3 09/10] KVM: s390: Fix ordering when adding to SCA Claudio Imbrenda
2026-07-27 17:12 ` sashiko-bot
2026-07-27 15:02 ` [PATCH v3 10/10] KVM: s390: Fix cleanup in kvm_s390_pv_create_cpu() Claudio Imbrenda
2026-07-27 17:18 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260727163329.3996E1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.