From: sashiko-bot@kernel.org
To: "Eric Farman" <farman@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH v6 04/10] s390/vfio_ccw: ensure first IDAW remains constant
Date: Sun, 26 Jul 2026 17:40:11 +0000 [thread overview]
Message-ID: <20260726174012.37EC91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260726172153.1818056-5-farman@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Out of Bounds Memory Read in get_guest_idal for Format-1 IDALs
--
--- Patch [4]: [PATCH v6 04/10] s390/vfio_ccw: ensure first IDAW remains constant ---
commit c3bce41a8cd87ec5448bafb458598e338f70a2c4
Author: Eric Farman <farman@linux.ibm.com>
s390/vfio_ccw: ensure first IDAW remains constant
The first IDAW in a list does not need to be on a 2K/4K boundary
like all others, and so is read separately to accurately calculate
the size of the buffer needed to read the full IDAL. This commit
verifies that the address found in the first IDAW is unchanged between
reads to ensure a consistent set of IDAWs being worked with.
> diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
> index af632f9d54535..6275794751cb4 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.c
> +++ b/drivers/s390/cio/vfio_ccw_cp.c
> @@ -523,6 +523,7 @@ static dma64_t *get_guest_idal(struct ccw1 *ccw, struct channel_program *cp, int
> &container_of(cp, struct vfio_ccw_private, cp)->vdev;
> dma64_t *idaws;
> dma32_t *idaws_f1;
> + u64 first_idaw;
> int idal_len = idaw_nr * sizeof(*idaws);
[Severity: High]
This is a pre-existing issue, but does this unconditionally calculate the DMA
read length assuming 8-byte IDAWs?
Since sizeof(*idaws) evaluates to 8 for the dma64_t type, but Format-1 IDAWs
are only 4 bytes (dma32_t), idal_len appears to be double the required size
for Format-1.
When this over-calculated size is later passed to vfio_dma_rw() in this same
function:
get_guest_idal() {
...
ret = vfio_dma_rw(vdev, dma32_to_u32(ccw->cda), idaws, idal_len, false);
...
}
Could this cause valid I/O requests to fail if the over-calculated length
happens to cross into an unmapped adjacent guest memory page?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260726172153.1818056-1-farman@linux.ibm.com?part=4
next prev parent reply other threads:[~2026-07-26 17:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-26 17:21 [PATCH v6 00/10] s390/vfio_ccw fixes Eric Farman
2026-07-26 17:21 ` [PATCH v6 01/10] s390/vfio_ccw: free all memory if cp_init() fails Eric Farman
2026-07-26 17:34 ` sashiko-bot
2026-07-26 17:21 ` [PATCH v6 02/10] s390/vfio_ccw: limit the number of channel program segments Eric Farman
2026-07-26 17:32 ` sashiko-bot
2026-07-26 17:21 ` [PATCH v6 03/10] s390/vfio_ccw: fix out of bounds check on CCW array Eric Farman
2026-07-26 17:27 ` sashiko-bot
2026-07-26 17:21 ` [PATCH v6 04/10] s390/vfio_ccw: ensure first IDAW remains constant Eric Farman
2026-07-26 17:40 ` sashiko-bot [this message]
2026-07-26 17:21 ` [PATCH v6 05/10] s390/vfio_ccw: calculate idal length based on idaw type Eric Farman
2026-07-26 17:36 ` sashiko-bot
2026-07-26 17:21 ` [PATCH v6 06/10] s390/vfio_ccw: ensure index for read/write regions are within range Eric Farman
2026-07-26 17:38 ` sashiko-bot
2026-07-26 17:21 ` [PATCH v6 07/10] s390/vfio_ccw: cancel existing workqueues Eric Farman
2026-07-26 17:38 ` sashiko-bot
2026-07-26 17:21 ` [PATCH v6 08/10] s390/vfio_ccw: move cp cleanup out of not operational Eric Farman
2026-07-26 17:40 ` sashiko-bot
2026-07-26 17:21 ` [PATCH v6 09/10] s390/vfio_ccw: implement a channel program mutex Eric Farman
2026-07-26 17:40 ` sashiko-bot
2026-07-26 17:21 ` [PATCH v6 10/10] s390/vfio_ccw: implement a crw lock Eric Farman
2026-07-26 17:39 ` 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=20260726174012.37EC91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=farman@linux.ibm.com \
--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 \
/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