Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Christoph Schlameuss" <schlameuss@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.vom>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH v4 15/20] KVM: s390: vsie: Guard against invalid CPU address
Date: Wed, 12 Aug 2026 16:23:30 +0000	[thread overview]
Message-ID: <20260812162330.9C0DA1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260812-vsie-sigpi-v4-15-f19e49666315@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The newly added bounds check for `scb_o->icpua` is completely ineffective due to a signed-integer mismatch and a Time-of-Check to Time-of-Use (TOCTOU) race condition. A malicious guest can bypass this check, leading to a massive out-of-bounds array access and severe hypervisor memory corruption.
--

--- Patch [15]: [PATCH v4 15/20] KVM: s390: vsie: Guard against invalid CPU address ---
commit b018701df60566888acc3dc5acc8b060071a7256
Author: Christoph Schlameuss <schlameuss@linux.ibm.com>

KVM: s390: vsie: Guard against invalid CPU address
    
Inject a specification interrupt if the CPU address is above 255.
This adds a check to ensure compliance with architectural limits and
guard against out-of-bounds accesses.

> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
> --- a/arch/s390/kvm/vsie.c
> +++ b/arch/s390/kvm/vsie.c
> @@ -2169,6 +2169,11 @@ int kvm_s390_handle_vsie(struct kvm_vcpu *vcpu)
>  		return kvm_s390_inject_program_int(vcpu, PGM_ADDRESSING);
>  	scb_o = (struct kvm_s390_sie_block *)phys_to_virt(scb_hpa);
>  
> +	if (scb_o->icpua >= KVM_S390_MAX_VSIE_VCPUS) {

[Severity: Critical]
Is it possible for icpua to be a negative value? If icpua is a signed 16-bit
integer, a negative value would bypass this check.

Additionally, since scb_o resides in guest memory, is this check subject to a
Time-of-Check to Time-of-Use (TOCTOU) race? A guest could potentially mutate
icpua after this check passes but before it is fetched again.

For example, could the guest change the value in memory before the secondary
fetch occurs later in kvm_s390_handle_vsie():

vsie_page = get_vsie_page_cpu_nr(vcpu, vsie_sca, scb_addr, scb_o->icpua);

If a bypassed or mutated value is implicitly cast to a large unsigned index
in get_vsie_page_cpu_nr(), could this result in an out-of-bounds read and
write on vsie_sca->pages[cpu_nr]?

> +		rc = kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);
> +		goto out_unpin;
> +	}
> +
>  	if (!use_ssca(vcpu->kvm, scb_o)) {
>  		/* get the vsie_page with pinned scb_o */
>  		vsie_page = get_vsie_page(vcpu, scb_addr);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812-vsie-sigpi-v4-0-f19e49666315@linux.ibm.com?part=15

  reply	other threads:[~2026-08-12 16:23 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 13:52 [PATCH v4 00/20] KVM: s390: vsie: Add VSIE SIGP ECALL and SRSI Interpretation Christoph Schlameuss
2026-08-12 13:52 ` [PATCH v4 01/20] KVM: s390: vsie: Add SCAO read and write helpers Christoph Schlameuss
2026-08-12 13:58   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 02/20] KVM: s390: vsie: Move SCAO validation into a function Christoph Schlameuss
2026-08-12 15:13   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 03/20] KVM: s390: vsie: Add vsie_interp_extf detection Christoph Schlameuss
2026-08-12 13:58   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 04/20] KVM: s390: vsie: Add ssca_block and ssca_entry structs Christoph Schlameuss
2026-08-12 13:57   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 05/20] KVM: s390: vsie: Move pin/unpin_scb methods Christoph Schlameuss
2026-08-12 14:03   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 06/20] KVM: s390: vsie: Move pin/unpin guest page Christoph Schlameuss
2026-08-12 14:08   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 07/20] KVM: s390: vsie: Move release/acquire gmap shadow Christoph Schlameuss
2026-08-12 14:02   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 08/20] KVM: s390: vsie: Create helpers to alloc and free vsie_pages Christoph Schlameuss
2026-08-12 14:04   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 09/20] KVM: s390: vsie: Replace radix_tree with xarray addr_to_page Christoph Schlameuss
2026-08-12 14:03   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 10/20] KVM: s390: vsie: Add helper to release gmap shadow Christoph Schlameuss
2026-08-12 14:04   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 11/20] KVM: s390: vsie: Lazily keep original scb pinned after vsie exit Christoph Schlameuss
2026-08-12 15:28   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 12/20] KVM: s390: vsie: Add helper to pin and unpin multiple guest pages Christoph Schlameuss
2026-08-12 14:11   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 13/20] KVM: s390: vsie: Add struct vsie_sca with pin and unpin methods Christoph Schlameuss
2026-08-12 15:43   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 14/20] KVM: s390: vsie: Shadow VSIE SCA in guest-1 Christoph Schlameuss
2026-08-12 16:10   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 15/20] KVM: s390: vsie: Guard against invalid CPU address Christoph Schlameuss
2026-08-12 16:23   ` sashiko-bot [this message]
2026-08-12 13:52 ` [PATCH v4 16/20] KVM: s390: vsie: Allow guest-3 cpu add and remove with ssca Christoph Schlameuss
2026-08-12 16:40   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 17/20] KVM: s390: vsie: Add VSIE max shadow configuration Christoph Schlameuss
2026-08-12 16:53   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 18/20] KVM: s390: vsie: Add VSIE shadow stat counters Christoph Schlameuss
2026-08-12 17:02   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 19/20] KVM: s390: vsie: Create minimal scb shadows for not running g3 blocks Christoph Schlameuss
2026-08-12 17:26   ` sashiko-bot
2026-08-12 13:52 ` [PATCH v4 20/20] KVM: s390: vsie: Enable use of VSIE SSCA Christoph Schlameuss

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=20260812162330.9C0DA1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.vom \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=schlameuss@linux.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox