From: sashiko-bot@kernel.org
To: "Richard Cheng" <icheng@nvidia.com>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH v3 1/3] cxl/features: Reject Get Feature count larger than the output buffer
Date: Fri, 26 Jun 2026 10:54:07 +0000 [thread overview]
Message-ID: <20260626105407.909B31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626104102.53892-2-icheng@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Missing bounds checks on user-provided input length in `cxlctl_fw_rpc()` and `cxlctl_set_feature()`, leading to out-of-bounds reads and potential ZERO_SIZE_PTR crashes.
--
commit 1f7098b182e4cdaf480b19545ca818cbf043bd29
Author: Richard Cheng <icheng@nvidia.com>
cxl/features: Reject Get Feature count larger than the output buffer
cxlctl_get_feature() sizes its output buffer from the user's
fwctl_rpc.out_len, but the device is told to write count bytes into
rpc_out->payload. This adds bounds checking against out_size to prevent
overflowing the allocated buffer.
> diff --git a/drivers/cxl/core/features.c b/drivers/cxl/core/features.c
> index 85185af46b72d..9c714ee42a411 100644
> --- a/drivers/cxl/core/features.c
> +++ b/drivers/cxl/core/features.c
> @@ -471,6 +471,10 @@ static void *cxlctl_get_feature(struct cxl_features_state *cxlfs,
> if (!count)
> return ERR_PTR(-EINVAL);
>
> + if (out_size < offsetof(struct fwctl_rpc_cxl_out, payload) ||
> + count > out_size - offsetof(struct fwctl_rpc_cxl_out, payload))
> + return ERR_PTR(-EINVAL);
> +
[Severity: Critical]
This is a pre-existing issue, but while we are adding bounds checks for
the output buffer here, does cxlctl_fw_rpc() also need to validate the
user-provided in_len?
If the ioctl is called with an in_len of 0, could dereferencing
rpc_in->opcode in cxlctl_fw_rpc() lead to a zero-size pointer crash?
Similarly, in cxlctl_set_feature(), the operation size is calculated without
verifying in_len:
data_size = rpc_in->op_size - sizeof(feat_in->hdr);
Could a small in_len combined with a large rpc_in->op_size result in an
out-of-bounds read, copying adjacent kernel heap memory into the hardware
mailbox? Would validating in_len against op_size in cxlctl_fw_rpc() prevent
this?
> struct fwctl_rpc_cxl_out *rpc_out __free(kvfree) =
> kvzalloc(out_size, GFP_KERNEL);
> if (!rpc_out)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626104102.53892-1-icheng@nvidia.com?part=1
next prev parent reply other threads:[~2026-06-26 10:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 10:40 [PATCH v3 0/3] cxl/features: Bounds-check the fwctl feature commands Richard Cheng
2026-06-26 10:41 ` [PATCH v3 1/3] cxl/features: Reject Get Feature count larger than the output buffer Richard Cheng
2026-06-26 10:54 ` sashiko-bot [this message]
2026-06-30 2:50 ` Richard Cheng
2026-06-26 10:41 ` [PATCH v3 2/3] cxl/features: Reject Set Features output buffer smaller than the header Richard Cheng
2026-06-26 10:56 ` sashiko-bot
2026-06-30 2:51 ` Richard Cheng
2026-06-26 10:41 ` [PATCH v3 3/3] cxl/features: Clamp Get Feature output size to the remaining buffer Richard Cheng
2026-06-26 10:52 ` sashiko-bot
2026-06-30 2:57 ` Richard Cheng
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=20260626105407.909B31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=icheng@nvidia.com \
--cc=linux-cxl@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.