From: sashiko-bot@kernel.org
To: "Eric Farman" <farman@linux.ibm.com>
Cc: linux-s390@vger.kernel.org,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
kvm@vger.kernel.org, "Vasily Gorbik" <gor@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [PATCH v1 4/6] s390/vfio_ccw: copy maximum possible IDAL from guest
Date: Tue, 14 Jul 2026 23:34:24 +0000 [thread overview]
Message-ID: <20260714233425.092371F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714232208.1683788-5-farman@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] calc_max_idal_len() returns a word count instead of a byte length, causing truncated guest memory reads and silent guest memory corruption.
--
--- Patch [4]: [PATCH v1 4/6] s390/vfio_ccw: copy maximum possible IDAL from guest ---
commit 3ab642e4c4a6646b5b0bec62ab380c4cc0ea0ac2
Author: Eric Farman <farman@linux.ibm.com>
s390/vfio_ccw: copy maximum possible IDAL from guest
An Indirect Data Address word is always 2K/4K aligned (depending on
format/type), except for the first word in a list. This unaligned
word makes calculating the number of addresses in a list challenging.
The current code attempts to be efficient about this by reading the
first word before making its calculations, but it introduces
inefficiencies trying to do the math on supposedly equal values.
> diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
> index 74b1f25e01e72..dac53e26509e5 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.c
> +++ b/drivers/s390/cio/vfio_ccw_cp.c
> @@ -523,16 +523,24 @@ static int ccwchain_fetch_tic(struct ccw1 *ccw,
> return -EFAULT;
> }
>
> +static int calc_max_idal_len(struct ccw1 *ccw, struct channel_program *cp)
> +{
> + int idal_size = idal_is_2k(cp) ? PAGE_SIZE / 2 : PAGE_SIZE;
> + int idal_mask = ~(idal_size - 1);
> + int idal_len = idal_size - (ccw->cda & ~idal_mask);
> +
> + /* This overestimates for Format-1 or 2K-Format-2 IDAWs */
> + return idal_len / 8;
> +}
> +
> static dma64_t *get_guest_idal(struct ccw1 *ccw, struct channel_program *cp, int idaw_nr)
> {
> - struct vfio_device *vdev =
> - &container_of(cp, struct vfio_ccw_private, cp)->vdev;
> dma64_t *idaws;
> dma32_t *idaws_f1;
> int idal_len = idaw_nr * sizeof(*idaws);
> int idaw_size = idal_is_2k(cp) ? PAGE_SIZE / 2 : PAGE_SIZE;
> int idaw_mask = ~(idaw_size - 1);
> - int i, ret;
> + int i;
>
> idaws = kzalloc_objs(*idaws, idaw_nr, GFP_DMA | GFP_KERNEL);
> if (!idaws)
> @@ -540,11 +548,7 @@ static dma64_t *get_guest_idal(struct ccw1 *ccw, struct channel_program *cp, int
>
> if (ccw_is_idal(ccw)) {
> /* Copy IDAL from guest */
> - ret = vfio_dma_rw(vdev, dma32_to_u32(ccw->cda), idaws, idal_len, false);
> - if (ret) {
> - kfree(idaws);
> - return ERR_PTR(ret);
> - }
> + memcpy(idaws, cp->guest_idal, idal_len);
> } else {
> /* Fabricate an IDAL based off CCW data address */
> if (cp->orb.cmd.c64) {
[ ... ]
> @@ -586,7 +590,7 @@ static int ccw_count_idaws(struct ccw1 *ccw,
> struct vfio_device *vdev =
> &container_of(cp, struct vfio_ccw_private, cp)->vdev;
> u64 iova;
> - int size = cp->orb.cmd.c64 ? sizeof(u64) : sizeof(u32);
> + int size = calc_max_idal_len(ccw, cp);
> int ret;
> int bytes = 1;
>
> @@ -596,10 +600,13 @@ static int ccw_count_idaws(struct ccw1 *ccw,
> if (ccw_is_idal(ccw)) {
> /* Read first IDAW to check its starting address. */
> /* All subsequent IDAWs will be 2K- or 4K-aligned. */
> - ret = vfio_dma_rw(vdev, dma32_to_u32(ccw->cda), &iova, size, false);
> + ret = vfio_dma_rw(vdev, dma32_to_u32(ccw->cda),
> + cp->guest_idal, size, false);
[Severity: High]
Does this pass a word count instead of a byte count to vfio_dma_rw()?
calc_max_idal_len() returns a word count because it divides the remaining bytes
by 8. When this value is stored in size and passed to vfio_dma_rw(), it seems
it will read at most 1/8th of the required IDAL data.
Later in get_guest_idal(), the code copies the full required byte length from
the partially-filled cp->guest_idal buffer:
memcpy(idaws, cp->guest_idal, idal_len);
Could this result in copying stale or uninitialized data to the host IDAL,
causing the hardware to perform DMA to incorrect guest physical addresses?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260714232208.1683788-1-farman@linux.ibm.com?part=4
next prev parent reply other threads:[~2026-07-14 23:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 23:22 [PATCH v1 0/6] s390/vfio_ccw fixes Eric Farman
2026-07-14 23:22 ` [PATCH v1 1/6] s390/vfio_ccw: fix out of bounds check on CCW array Eric Farman
2026-07-14 23:37 ` sashiko-bot
2026-07-14 23:22 ` [PATCH v1 2/6] s390/vfio_ccw: limit the number of channel program segments Eric Farman
2026-07-14 23:38 ` sashiko-bot
2026-07-14 23:22 ` [PATCH v1 3/6] s390/vfio_ccw: free all memory if cp_init() fails Eric Farman
2026-07-14 23:36 ` sashiko-bot
2026-07-14 23:22 ` [PATCH v1 4/6] s390/vfio_ccw: copy maximum possible IDAL from guest Eric Farman
2026-07-14 23:34 ` sashiko-bot [this message]
2026-07-14 23:22 ` [PATCH v1 5/6] s390/vfio_ccw: ensure index for read/write regions are within range Eric Farman
2026-07-14 23:45 ` sashiko-bot
2026-07-14 23:22 ` [PATCH v1 6/6] s390/vfio_ccw: lock I/O resources alongside I/O regions Eric Farman
2026-07-14 23:38 ` 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=20260714233425.092371F000E9@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