Linux s390 Architecture development
 help / color / mirror / Atom feed
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>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	linux-s390@vger.kernel.org, kvm@vger.kernel.org,
	"Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [GIT PULL v1 11/11] s390/uv: Prevent potential out-of-bounds read
Date: Fri, 04 Sep 2026 06:27:16 +0000	[thread overview]
Message-ID: <20260904062717.52E361F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260904060647.562443-12-imbrenda@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Potential infinite loop in `uvio_get_list` if UVC hardware returns `UVC_RC_MORE_DATA` but fails to advance `next_secret_idx`.
- [High] Missing bounds check on `num_secr_stored` against array size 85, leading to potential out-of-bounds reads and information leaks.
--

commit 3bddf93bb1450f001c28919a0ec81368564fe49c
Author: Steffen Eiden <seiden@linux.ibm.com>

s390/uv: Prevent potential out-of-bounds read

When the system has more than 85 secrets, the uv_secret_list struct array
only holds up to 85 items per page, resulting in an out of bounds read in
find_secret_in_page if the targeted secret is in the next page or not
stored at all. Fix this by looping over the per sub-list count of stored
secrets instead of the overall count.

> diff --git a/arch/s390/kernel/uv.c b/arch/s390/kernel/uv.c
> index 52003c463fad0..8ea9dd7704ffc 100644
> --- a/arch/s390/kernel/uv.c
> +++ b/arch/s390/kernel/uv.c
> @@ -825,7 +825,7 @@ static int find_secret_in_page(const u8 secret_id[UV_SECRET_ID_LEN],
>  {
>  	u16 i;
>  
> -	for (i = 0; i < list->total_num_secrets; i++) {
> +	for (i = 0; i < list->num_secr_stored; i++) {

[Severity: High]
This is a pre-existing issue, but does list->num_secr_stored need to be
bounds checked against the size of the secrets[] array (85) before being
used as a loop limit?

If the Ultravisor firmware returns a num_secr_stored value greater than 85,
could this still result in an out-of-bounds read in find_secret_in_page()?

This same missing bounds check appears in uvio_get_list():

drivers/s390/char/uvdevice.c:uvio_get_list() {
    ...
		copy_len = sizeof(list->secrets[0]) * list->num_secr_stored;
		if (copy_to_user(user_buf + user_off, list->secrets, copy_len))
			return -EFAULT;
    ...
}

Could an anomalously large num_secr_stored here cause copy_to_user() to copy
kernel memory beyond the allocated page out to user-space?

[Severity: High]
This is also a pre-existing issue, but looking at uvio_get_list() in
drivers/s390/char/uvdevice.c, is there a potential infinite loop?

drivers/s390/char/uvdevice.c:uvio_get_list() {
    ...
	do {
		uv_list_secrets(list, list->next_secret_idx, &uv_ioctl->uv_rc,
				&uv_ioctl->uv_rrc);
		if (uv_ioctl->uv_rc != UVC_RC_EXECUTED &&
		    uv_ioctl->uv_rc != UVC_RC_MORE_DATA)
			break;

		copy_len = sizeof(list->secrets[0]) * list->num_secr_stored;
		...
		user_off += copy_len;
		num_secrets_stored += list->num_secr_stored;
	} while (uv_ioctl->uv_rc == UVC_RC_MORE_DATA &&
		 user_off + sizeof(*list) <= uv_ioctl->argument_len);
    ...
}

If the hardware/firmware returns UVC_RC_MORE_DATA but yields
list->num_secr_stored == 0, user_off does not increment. If
list->next_secret_idx is also not advanced by the hardware, could this loop
indefinitely and cause a CPU stall?

>  		if (memcmp(secret_id, list->secrets[i].id, UV_SECRET_ID_LEN) == 0) {
>  			*secret = list->secrets[i].hdr;
>  			return 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904060647.562443-1-imbrenda@linux.ibm.com?part=11

      reply	other threads:[~2026-09-04  6:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04  6:06 [GIT PULL v1 00/11] KVM: s390: Misc fixes Claudio Imbrenda
2026-09-04  6:06 ` [GIT PULL v1 01/11] KVM: s390: Fix dirty marking in adapter_indicators_set*() Claudio Imbrenda
2026-09-04  6:15   ` sashiko-bot
2026-09-04  6:06 ` [GIT PULL v1 02/11] KVM: s390: Fix compile warning for kvm_s390_update_cmma_dirty() Claudio Imbrenda
2026-09-04  6:13   ` sashiko-bot
2026-09-04  6:06 ` [GIT PULL v1 03/11] KVM: s390: Fix _gaccess_shadow_fault() Claudio Imbrenda
2026-09-04  6:18   ` sashiko-bot
2026-09-04  6:06 ` [GIT PULL v1 04/11] KVM: s390: Refactor dat_set_slot() Claudio Imbrenda
2026-09-04  6:23   ` sashiko-bot
2026-09-04  6:06 ` [GIT PULL v1 05/11] KVM: s390: Move all code into s390_kvm_mmu_prepare_memory_region() Claudio Imbrenda
2026-09-04  6:19   ` sashiko-bot
2026-09-04  6:06 ` [GIT PULL v1 06/11] KVM: s390: Add missing srcu in kvm_s390_set_irq_state() Claudio Imbrenda
2026-09-04  6:16   ` sashiko-bot
2026-09-04  6:06 ` [GIT PULL v1 07/11] KVM: s390: Fix potential races in dat skey functions Claudio Imbrenda
2026-09-04  6:20   ` sashiko-bot
2026-09-04  6:06 ` [GIT PULL v1 08/11] KVM: s390: Fix race in _destroy_pages_crste() Claudio Imbrenda
2026-09-04  6:22   ` sashiko-bot
2026-09-04  6:06 ` [GIT PULL v1 09/11] s390/vfio-ap: fix KVM GISC and page leak when queue removed from host config Claudio Imbrenda
2026-09-04  6:22   ` sashiko-bot
2026-09-04  6:06 ` [GIT PULL v1 10/11] s390/uv: Fix loop condition in uv_find_secrets Claudio Imbrenda
2026-09-04  6:20   ` sashiko-bot
2026-09-04  6:06 ` [GIT PULL v1 11/11] s390/uv: Prevent potential out-of-bounds read Claudio Imbrenda
2026-09-04  6:27   ` sashiko-bot [this message]

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=20260904062717.52E361F00A3E@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox