From: Richard Cheng <icheng@nvidia.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH v3 1/3] cxl/features: Reject Get Feature count larger than the output buffer
Date: Tue, 30 Jun 2026 10:50:57 +0800 [thread overview]
Message-ID: <akMu49Z1Xcm96XWE@MWDK4CY14F> (raw)
In-Reply-To: <20260626105407.909B31F000E9@smtp.kernel.org>
On Fri, Jun 26, 2026 at 10:54:07AM +0800, sashiko-bot@kernel.org wrote:
> 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
I think this is addressed here.
https://lore.kernel.org/linux-cxl/20260620-cxl-fwctl-oob-v1-1-5758e34d784a@gmail.com/
--Richard
next prev parent reply other threads:[~2026-06-30 2:51 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
2026-06-30 2:50 ` Richard Cheng [this message]
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=akMu49Z1Xcm96XWE@MWDK4CY14F \
--to=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.