All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Richard Cheng" <icheng@nvidia.com>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH v3 2/3] cxl/features: Reject Set Features output buffer smaller than the header
Date: Fri, 26 Jun 2026 10:56:11 +0000	[thread overview]
Message-ID: <20260626105612.B7CB81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626104102.53892-3-icheng@nvidia.com>

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

Pre-existing issues:
- [Critical] Missing validation of the user-provided `in_len` parameter allows a `ZERO_SIZE_PTR` dereference and severe out-of-bounds reads in the CXL FWCTL driver.
--

commit 149380dfe9472c578ca9fd76d4e5bb0c5ac85c19
Author: Richard Cheng <icheng@nvidia.com>

cxl/features: Reject Set Features output buffer smaller than the header

cxlctl_set_feature() sizes its output buffer from the user's
fwctl_rpc.out_len but never checks it is large enough to hold even the
fwctl_rpc_cxl_out header. With out_len == 0 , kvzalloc() returns
ZERO_SIZE_PTR, which passes the !rpc_out check, the subsequent
rpc_out->size = 0 then writes through the poison pointer.

> diff --git a/drivers/cxl/core/features.c b/drivers/cxl/core/features.c
> index 9c714ee42a411..ed18ccb5e236e 100644
> --- a/drivers/cxl/core/features.c
> +++ b/drivers/cxl/core/features.c
> @@ -520,6 +520,9 @@ static void *cxlctl_set_feature(struct cxl_features_state *cxlfs,
>  	flags = le32_to_cpu(feat_in->flags);
>  	out_size = *out_len;
>  
> +	if (out_size < offsetof(struct fwctl_rpc_cxl_out, payload))
> +		return ERR_PTR(-EINVAL);
> +

[Severity: Critical]
This is a pre-existing issue, but missing validation of the user-provided
in_len parameter allows a ZERO_SIZE_PTR dereference and out-of-bounds reads.

If a malicious user passes in_len=0 to the FWCTL_RPC ioctl, kvzalloc(0)
returns the ZERO_SIZE_PTR constant (0x10) in
drivers/fwctl/main.c:fwctl_cmd_rpc():

	void *inbuf __free(kvfree) = kvzalloc(cmd->in_len, GFP_KERNEL_ACCOUNT);

The driver unconditionally dereferences this pointer in
drivers/cxl/core/features.c:cxlctl_fw_rpc():

	const struct fwctl_rpc_cxl *rpc_in = in;
	u16 opcode = rpc_in->opcode;

Also, if a user provides a small in_len but specifies a massive op_size in
the command header, handlers like cxlctl_set_feature() will read out of
bounds of the kvzalloc'd heap buffer and transmit that data to the hardware
mailbox:

	data_size = rpc_in->op_size - sizeof(feat_in->hdr);
	rc = cxl_set_feature(cxl_mbox, &feat_in->uuid,
			     feat_in->version, feat_in->feat_data,
			     data_size, flags, offset, &return_code);

Should there be validation of in_len before casting and accessing the input
buffer, as well as a check to ensure rpc_in->op_size does not exceed in_len?

>  	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=2

  reply	other threads:[~2026-06-26 10:56 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
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 [this message]
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=20260626105612.B7CB81F000E9@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.