From: sashiko-bot@kernel.org
To: "Eric Farman" <farman@linux.ibm.com>
Cc: "Vasily Gorbik" <gor@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v9 01/10] s390/vfio_ccw: free all memory if cp_init() fails
Date: Tue, 28 Jul 2026 04:03:04 +0000 [thread overview]
Message-ID: <20260728040304.9C7E91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260728033022.2658232-2-farman@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Unbounded mutual recursion in `ccwchain_handle_ccw` and `ccwchain_loop_tic` allows a malicious guest to trigger a host kernel stack overflow or kernel memory exhaustion via a long linear chain of TICs.
--
--- Patch [1]: [PATCH v9 01/10] s390/vfio_ccw: free all memory if cp_init() fails ---
commit 0328e77fed7449f2970377374db30134792fce5b
Author: Eric Farman <farman@linux.ibm.com>
s390/vfio_ccw: free all memory if cp_init() fails
The routine cp_free() cannot be used to free memory if cp_init() fails
before initialization completes. This patch moves cleanup outside the
recursive loop to properly free all segments created by a Transfer in
Channel (TIC) if an error occurs.
> 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);
[Severity: Critical]
This is a pre-existing issue, but does this mutually recursive call chain
between ccwchain_handle_ccw() and ccwchain_loop_tic() allow a malicious
guest to trigger a host kernel stack overflow?
If a guest constructs a channel program with a long linear sequence of
Transfer In Channel (TIC) commands, each pointing to a distinct guest
physical address, the host processes it by recursively entering:
ccwchain_handle_ccw()
ccwchain_loop_tic()
ccwchain_handle_ccw()
Could this unbounded recursion exhaust the host kernel stack and cause a
denial of service?
> - if (ret)
> - ccwchain_free(chain);
> -
> return ret;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260728033022.2658232-1-farman@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-07-28 4:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 3:30 [PATCH v9 00/10] s390/vfio_ccw fixes Eric Farman
2026-07-28 3:30 ` [PATCH v9 01/10] s390/vfio_ccw: free all memory if cp_init() fails Eric Farman
2026-07-28 4:03 ` sashiko-bot [this message]
2026-07-28 3:30 ` [PATCH v9 02/10] s390/vfio_ccw: limit the number of channel program segments Eric Farman
2026-07-28 3:52 ` sashiko-bot
2026-07-28 3:30 ` [PATCH v9 03/10] s390/vfio_ccw: fix out of bounds check on CCW array Eric Farman
2026-07-28 3:59 ` sashiko-bot
2026-07-28 3:30 ` [PATCH v9 04/10] s390/vfio_ccw: ensure first IDAW remains constant Eric Farman
2026-07-28 3:59 ` sashiko-bot
2026-07-28 3:30 ` [PATCH v9 05/10] s390/vfio_ccw: calculate idal length based on idaw type Eric Farman
2026-07-28 4:00 ` sashiko-bot
2026-07-28 3:30 ` [PATCH v9 06/10] s390/vfio_ccw: ensure index for read/write regions are within range Eric Farman
2026-07-28 4:02 ` sashiko-bot
2026-07-28 3:30 ` [PATCH v9 07/10] s390/vfio_ccw: cancel existing workqueues Eric Farman
2026-07-28 4:02 ` sashiko-bot
2026-07-28 3:30 ` [PATCH v9 08/10] s390/vfio_ccw: move cp cleanup out of not operational Eric Farman
2026-07-28 4:01 ` sashiko-bot
2026-07-28 14:48 ` Matthew Rosato
2026-07-28 3:30 ` [PATCH v9 09/10] s390/vfio_ccw: selectively expand io_mutex Eric Farman
2026-07-28 4:05 ` sashiko-bot
2026-07-28 14:48 ` Matthew Rosato
2026-07-28 3:30 ` [PATCH v9 10/10] s390/vfio_ccw: implement a crw lock Eric Farman
2026-07-28 4:05 ` sashiko-bot
2026-07-28 14:45 ` [PATCH v9 00/10] s390/vfio_ccw fixes Christian Borntraeger
2026-07-28 14:53 ` 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=20260728040304.9C7E91F000E9@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