All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eric Farman" <farman@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH v2 1/7] s390/vfio_ccw: free all memory if cp_init() fails
Date: Mon, 20 Jul 2026 20:31:06 +0000	[thread overview]
Message-ID: <20260720203106.655431F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720201931.976660-2-farman@linux.ibm.com>

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

Pre-existing issues:
- [High] An untrusted guest can cause kernel stack exhaustion or memory exhaustion (OOM) by providing a channel program with a deeply nested, linear chain of Transfer in Channel (TIC) CCWs.
- [High] An off-by-one loop condition in `ccwchain_calc_length()` causes an out-of-bounds heap read.
--

--- Patch [1]: [PATCH v2 1/7] s390/vfio_ccw: free all memory if cp_init() fails ---
commit 6db32c0a42b6a98e43b665d960a38dfaf7572bca
Author: Eric Farman <farman@linux.ibm.com>

s390/vfio_ccw: free all memory if cp_init() fails

This commit updates cp_init() to address a memory leak when initialization
fails. It performs the cleanup outside of the recursive handling logic to
avoid leaking segments created by Transfer in Channel (TIC) commands.

> diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
> index 7561aa7d3e017..086d1b54bdb05 100644
> --- a/drivers/s390/cio/vfio_ccw_cp.c
> +++ b/drivers/s390/cio/vfio_ccw_cp.c
> @@ -455,9 +455,6 @@ static int ccwchain_handle_ccw(dma32_t cda, struct channel_program *cp)
>  	/* Loop for tics on this new chain. */
>  	ret = ccwchain_loop_tic(chain, cp);
>  
> -	if (ret)
> -		ccwchain_free(chain);
> -

[Severity: High]
This is a pre-existing issue, but can this recursive call to
ccwchain_handle_ccw() cause kernel stack exhaustion?

Looking at ccwchain_loop_tic() in drivers/s390/cio/vfio_ccw_cp.c, it
recursively calls ccwchain_handle_ccw() for each forward-jumping TIC:

drivers/s390/cio/vfio_ccw_cp.c:ccwchain_loop_tic() {
        ...
        /* Build a ccwchain for the next segment */
        ret = ccwchain_handle_ccw(tic->cda, cp);
        ...
}

Since this happens without any depth tracking or overall chain count limits,
could an untrusted guest cause a panic or OOM by providing a channel program
with a deeply nested, linear chain of Transfer in Channel (TIC) CCWs?

[Severity: High]
This is a pre-existing issue, but does this off-by-one loop condition
in ccwchain_calc_length() cause an out-of-bounds heap read?

drivers/s390/cio/vfio_ccw_cp.c:ccwchain_calc_length() {
        ...
        } while (cnt < CCWCHAIN_LEN_MAX + 1);
        ...
}

If a guest VM supplies exactly 256 CCWs that all have the command-chaining
flag enabled, will the loop evaluate !ccw_is_chain(ccw) on the 257th
iteration?

This appears to dereference ccw one element past the allocated array on
cp->guest_cp, which could trigger memory debug splats or crashes.

>  	return ret;
>  }

[ ... ]

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

  reply	other threads:[~2026-07-20 20:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 20:19 [PATCH v2 0/7] s390/vfio_ccw fixes Eric Farman
2026-07-20 20:19 ` [PATCH v2 1/7] s390/vfio_ccw: free all memory if cp_init() fails Eric Farman
2026-07-20 20:31   ` sashiko-bot [this message]
2026-07-20 21:48   ` Farhan Ali
2026-07-21  0:01     ` Eric Farman
2026-07-20 20:19 ` [PATCH v2 2/7] s390/vfio_ccw: limit the number of channel program segments Eric Farman
2026-07-20 20:30   ` sashiko-bot
2026-07-20 20:53     ` Eric Farman
2026-07-20 20:19 ` [PATCH v2 3/7] s390/vfio_ccw: fix out of bounds check on CCW array Eric Farman
2026-07-20 20:38   ` sashiko-bot
2026-07-20 20:19 ` [PATCH v2 4/7] s390/vfio_ccw: ensure first IDAW remains constant Eric Farman
2026-07-20 20:33   ` sashiko-bot
2026-07-20 20:19 ` [PATCH v2 5/7] s390/vfio_ccw: ensure index for read/write regions are within range Eric Farman
2026-07-20 20:40   ` sashiko-bot
2026-07-20 20:19 ` [PATCH v2 6/7] s390/vfio_ccw: implement a channel program lock Eric Farman
2026-07-20 20:39   ` sashiko-bot
2026-07-20 20:19 ` [PATCH v2 7/7] s390/vfio_ccw: implement a crw lock Eric Farman
2026-07-20 20:47   ` 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=20260720203106.655431F000E9@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.