All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Claudio Imbrenda" <imbrenda@linux.ibm.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>
Subject: Re: [PATCH v3 2/4] KVM: s390: Fix dat_peek_cmma() overflow
Date: Tue, 16 Jun 2026 17:03:42 +0000	[thread overview]
Message-ID: <20260616170343.4E6961F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260616165110.360921-3-imbrenda@linux.ibm.com>

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

Pre-existing issues:
- [Critical] kvm_s390_get_cmma_bits() leaks uninitialized kernel heap memory to userspace because the vmalloc buffer is partially populated and skipped indices remain uninitialized.
--

commit f6af8b3c3817150f3fd3255f80c30b252be59298
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>

KVM: s390: Fix dat_peek_cmma() overflow

If userspace passes a start address that is out of bounds,
_dat_walk_gfn_range() will fail with -EFAULT, but state.end will not be
touched and will stay 0. This will cause *count to underflow and report
a very high number, and the function will end up erroneously reporting
success.

> diff --git a/arch/s390/kvm/dat.c b/arch/s390/kvm/dat.c
> index 4a41c0247ffa2..cffac7782c4bf 100644
> --- a/arch/s390/kvm/dat.c
> +++ b/arch/s390/kvm/dat.c
> @@ -1209,7 +1209,7 @@ int dat_peek_cmma(gfn_t start, union asce asce, unsigned int *count, u8 *values)
>  	int rc;
>  
>  	rc = _dat_walk_gfn_range(start, start + *count, asce, &ops, DAT_WALK_DEFAULT, &state);
> -	*count = state.end - start;
> +	*count = state.end >= start ? state.end - start : 0;

[Severity: Critical]
This is a pre-existing issue, but I noticed a potential information leak to
userspace related to how this count is populated.

In arch/s390/kvm/kvm-s390.c:kvm_s390_get_cmma_bits(), the buffer is
allocated with vmalloc() instead of vzalloc():

	values = vmalloc(args->count);

During the walk, __dat_peek_cmma_crste() can skip unmapped regions by
advancing state->end without writing to the values array:

	if (crstep->h.i)
		state->end = min(walk->end, next);

Similarly, __dat_get_cmma_pte() can skip clean pages within the max bit
distance without writing anything:

	if (!READ_ONCE(*pgste_of(ptep)).cmma_d)
		return 0;

Since this *count value directly determines how many bytes copy_to_user()
copies in kvm_s390_get_cmma_bits(), can this leak uninitialized kernel
memory to userspace if the skipped entries leave gaps in the array?

>  	/* Return success if at least one value was saved, otherwise an error. */
>  	return (rc == -EFAULT && *count > 0) ? 0 : rc;
>  }

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

  reply	other threads:[~2026-06-16 17:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16 16:51 [PATCH v3 0/4] KVM: s390: Fixes for gmap and _PAGE_UNUSED Claudio Imbrenda
2026-06-16 16:51 ` [PATCH v3 1/4] s390/mm: Fix handling of _PAGE_UNUSED pte bit Claudio Imbrenda
2026-06-16 16:51 ` [PATCH v3 2/4] KVM: s390: Fix dat_peek_cmma() overflow Claudio Imbrenda
2026-06-16 17:03   ` sashiko-bot [this message]
2026-06-16 16:51 ` [PATCH v3 3/4] KVM: s390: Do not set special large pages dirty Claudio Imbrenda
2026-06-16 17:10   ` sashiko-bot
2026-06-16 16:51 ` [PATCH v3 4/4] KVM: s390: Fix code typo in gmap_protect_asce_top_level() Claudio Imbrenda

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=20260616170343.4E6961F000E9@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.