From: sashiko-bot@kernel.org
To: "Claudio Imbrenda" <imbrenda@linux.ibm.com>
Cc: "Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
kvm@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v4 2/7] KVM: s390: Fix dat_peek_cmma() overflow
Date: Fri, 19 Jun 2026 16:07:40 +0000 [thread overview]
Message-ID: <20260619160740.DE7361F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260619155154.307572-3-imbrenda@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Uninitialized kernel memory leak in kvm_s390_get_cmma_bits() via vmalloc array.
- [High] kvm_s390_set_cmma_bits() silently ignores memory allocation failures.
--
commit 198324f8297a62f137ba34c4a9aa74e25bb30e54
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
KVM: s390: Fix dat_peek_cmma() overflow
This commit fixes an underflow in dat_peek_cmma() when userspace passes an
out-of-bounds start address. By enforcing that the count is set to zero if
the end address is smaller than the start address, it correctly propagates
the -EFAULT error instead of 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;
> /* Return success if at least one value was saved, otherwise an error. */
[Severity: Critical]
This isn't a bug introduced by this patch, but does the CMMA retrieval path
leak uninitialized kernel memory to userspace?
In kvm_s390_get_cmma_bits(), the values array is allocated with vmalloc():
arch/s390/kvm/kvm-s390.c:kvm_s390_get_cmma_bits() {
...
values = vmalloc(args->count);
if (!values)
...
}
During the page table walk, if __dat_peek_cmma_crste() encounters an invalid
CRSTE, it advances the boundary but leaves the corresponding state.values
unpopulated:
arch/s390/kvm/dat.c:__dat_peek_cmma_crste() {
...
if (crstep->h.i)
state->end = min(walk->end, next);
...
}
Similarly, __dat_get_cmma_pte() skips clean pages:
arch/s390/kvm/dat.c:__dat_get_cmma_pte() {
...
if (!READ_ONCE(*pgste_of(ptep)).cmma_d)
return 0;
...
}
Because vmalloc() does not zero-initialize memory, could these gaps in the
array leak kernel heap memory when the array is unconditionally copied back
to userspace using the advanced state.end count?
[Severity: High]
This is a pre-existing issue, but does kvm_s390_set_cmma_bits() silently
ignore memory allocation failures?
If vmalloc() fails to allocate the bits array, the code jumps to the out
label:
arch/s390/kvm/kvm-s390.c:kvm_s390_set_cmma_bits() {
...
bits = vmalloc(array_size(sizeof(*bits), args->count));
if (!bits)
goto out;
...
}
Since the return variable is initialized to 0 and not updated to a negative
error code like -ENOMEM before this jump, will this return 0 to userspace
and silently drop the CMMA bits, potentially leading to guest memory
attribute corruption during migration?
> return (rc == -EFAULT && *count > 0) ? 0 : rc;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619155154.307572-1-imbrenda@linux.ibm.com?part=2
next prev parent reply other threads:[~2026-06-19 16:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 15:51 [PATCH v4 0/7] KVM: s390: A bunch of gmap-related fixes Claudio Imbrenda
2026-06-19 15:51 ` [PATCH v4 1/7] s390/mm: Fix handling of _PAGE_UNUSED pte bit Claudio Imbrenda
2026-06-19 15:51 ` [PATCH v4 2/7] KVM: s390: Fix dat_peek_cmma() overflow Claudio Imbrenda
2026-06-19 16:07 ` sashiko-bot [this message]
2026-06-19 15:51 ` [PATCH v4 3/7] KVM: s390: Do not set special large pages dirty Claudio Imbrenda
2026-06-19 16:13 ` sashiko-bot
2026-06-19 15:51 ` [PATCH v4 4/7] KVM: s390: Fix code typo in gmap_protect_asce_top_level() Claudio Imbrenda
2026-06-19 15:51 ` [PATCH v4 5/7] KVM: s390: Fix handle_{sske,pfmf} under memory pressure Claudio Imbrenda
2026-06-19 15:51 ` [PATCH v4 6/7] KVM: s390: cmma: Fix cmma dirty tracking Claudio Imbrenda
2026-06-19 16:09 ` sashiko-bot
2026-06-19 15:51 ` [PATCH v4 7/7] KVM: s390: selftests: Fix cmma selftest Claudio Imbrenda
2026-06-19 16:03 ` 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=20260619160740.DE7361F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox