All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eric Farman" <farman@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/9] s390/vfio_ccw: limit the number of channel program segments
Date: Sat, 25 Jul 2026 15:39:20 +0000	[thread overview]
Message-ID: <20260725153921.0F3701F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260725152705.3958100-3-farman@linux.ibm.com>

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

Pre-existing issues:
- [High] The `ccwchain_calc_length` function can read out-of-bounds when evaluating a maximum-length CCW chain.
- [Medium] `vfio_dma_rw` unconditionally fetches exactly 2K bytes regardless of actual chain length.
--

--- Patch [2]: [PATCH v4 2/9] s390/vfio_ccw: limit the number of channel program segments ---
commit 329c62f260a235e5ffc6e09ecde7b4928c02051c
Author: Eric Farman <farman@linux.ibm.com>
Subject: s390/vfio_ccw: limit the number of channel program segments

This commit imposes a limit on the number of channel program segments
(linked by TIC) that can exist in a single channel program. It breaks
channel programs into segments when encountering a Transfer-In-Channel (TIC)
CCW and enforces a global limit on the number of segments to prevent unbounded
recursion.

[ ... ]
> diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
> index 086d1b54bdb05..1c2890d139c6b 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.c
> +++ b/drivers/s390/cio/vfio_ccw_cp.c
[ ... ]
> @@ -441,6 +442,10 @@ static int ccwchain_handle_ccw(dma32_t cda, struct channel_program *cp)
>  	if (len < 0)
>  		return len;
>  
> +	/* Limit number of chains in a single channel program */
> +	if (cp->ccwchain_count >= CCWCHAIN_COUNT_MAX)
> +		return -EINVAL;
> +

[Severity: Medium]
This isn't a bug introduced by this patch, but does the unconditional read of
2K bytes in ccwchain_handle_ccw() cause valid short programs to fail?

Earlier in ccwchain_handle_ccw(), the code performs a hardcoded 2K read before
calculating the actual chain length:

ccwchain_handle_ccw() {
    ...
    ret = vfio_dma_rw(vdev, gcda, cp->guest_cp,
                      CCWCHAIN_LEN_MAX * sizeof(struct ccw1), false);
    if (ret)
        return ret;
    ...
}

If a guest submits a short channel program located near the end of a mapped
memory region, and the adjacent page is unmapped, vfio_dma_rw() will fail the
entire transaction instead of returning a partial read.

Could this lead to rejection of valid channel programs based on their memory
layout?

[Severity: High]
This is a pre-existing issue, but can the length calculation read out of
bounds?

In ccwchain_calc_length(), which is called just before the new limit check,
the code evaluates a maximum-length CCW chain:

ccwchain_calc_length() {
    ...
    if (!ccw_is_chain(ccw) && !is_tic_within_range(ccw, iova, cnt))
        break;
    ...
}

If a guest VM submits a channel program where the first 256 CCWs all have
the chain flag set, the loop increments the counter to 257. On the 257th
iteration, calling ccw_is_chain(ccw) reads the flags field from guest_cp[256],
which is one element past the end of the allocated CCWCHAIN_LEN_MAX array.

Can an unprivileged guest trigger an out-of-bounds read by providing a
specially crafted channel program?

>  	/* Need alloc a new chain for this one. */
>  	chain = ccwchain_alloc(cp, len);
>  	if (!chain)
[ ... ]

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

  reply	other threads:[~2026-07-25 15:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25 15:26 [PATCH v4 0/9] s390/vfio_ccw fixes Eric Farman
2026-07-25 15:26 ` [PATCH v4 1/9] s390/vfio_ccw: free all memory if cp_init() fails Eric Farman
2026-07-25 15:42   ` sashiko-bot
2026-07-25 15:26 ` [PATCH v4 2/9] s390/vfio_ccw: limit the number of channel program segments Eric Farman
2026-07-25 15:39   ` sashiko-bot [this message]
2026-07-25 15:26 ` [PATCH v4 3/9] s390/vfio_ccw: fix out of bounds check on CCW array Eric Farman
2026-07-25 15:33   ` sashiko-bot
2026-07-25 16:09   ` Matthew Rosato
2026-07-25 15:27 ` [PATCH v4 4/9] s390/vfio_ccw: ensure first IDAW remains constant Eric Farman
2026-07-25 15:44   ` sashiko-bot
2026-07-25 15:27 ` [PATCH v4 5/9] s390/vfio_ccw: calculate idal length based on idaw type Eric Farman
2026-07-25 15:34   ` sashiko-bot
2026-07-25 15:27 ` [PATCH v4 6/9] s390/vfio_ccw: ensure index for read/write regions are within range Eric Farman
2026-07-25 15:42   ` sashiko-bot
2026-07-25 16:27   ` Matthew Rosato
2026-07-25 15:27 ` [PATCH v4 7/9] s390/vfio_ccw: move cp cleanup out of not operational Eric Farman
2026-07-25 15:42   ` sashiko-bot
2026-07-25 16:39   ` Matthew Rosato
2026-07-25 15:27 ` [PATCH v4 8/9] s390/vfio_ccw: implement a channel program mutex Eric Farman
2026-07-25 15:43   ` sashiko-bot
2026-07-25 17:04   ` Matthew Rosato
2026-07-25 15:27 ` [PATCH v4 9/9] s390/vfio_ccw: implement a crw lock Eric Farman
2026-07-25 15:46   ` sashiko-bot
2026-07-25 17:03   ` Matthew Rosato

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=20260725153921.0F3701F000E9@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 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.