From: sashiko-bot@kernel.org
To: "Richard Cheng" <icheng@nvidia.com>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH v5 1/7] cxl/features: Reject feature offset that overflows 16-bit field
Date: Thu, 13 Aug 2026 03:57:01 +0000 [thread overview]
Message-ID: <20260813035701.B628E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260813034538.13189-2-icheng@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The bounds check designed to prevent 16-bit offset wrap-around is off by one, making the final byte of the feature space inaccessible.
--
--- Patch [1]: [PATCH v5 1/7] cxl/features: Reject feature offset that overflows 16-bit field ---
commit 48e82cdf4087a2ffbeb7023fda65d3ff4f9b9c6f
Author: Richard Cheng <icheng@nvidia.com>
cxl/features: Reject feature offset that overflows 16-bit field
This commit adds bounds checking to prevent 16-bit offset wrap-around in CXL
feature commands. It also changes cxl_get_feature() to return ssize_t to
properly report errors instead of conflating them with a zero-byte result.
> diff --git a/drivers/cxl/core/features.c b/drivers/cxl/core/features.c
> index ba6d2a5acb74a..8d44ce8294978 100644
> --- a/drivers/cxl/core/features.c
> +++ b/drivers/cxl/core/features.c
[ ... ]
> @@ -235,7 +235,10 @@ size_t cxl_get_feature(struct cxl_mailbox *cxl_mbox, const uuid_t *feat_uuid,
> *return_code = CXL_MBOX_CMD_RC_INPUT;
>
> if (!feat_out || !feat_out_size)
> - return 0;
> + return -EINVAL;
> +
> + if (feat_out_size > U16_MAX - offset)
> + return -EINVAL;
[Severity: Medium]
Does this check contain an off-by-one error that rejects valid accesses to the
last byte of the feature space?
If a request targets the final byte of the 64KB feature space with
offset = 65535 and feat_out_size = 1, this evaluates to 1 > 65535 - 65535
(1 > 0), which is true, incorrectly rejecting the single-byte transfer.
>
> uuid_copy(&pi.uuid, feat_uuid);
> pi.selection = selection;
[ ... ]
> @@ -288,6 +291,9 @@ int cxl_set_feature(struct cxl_mailbox *cxl_mbox,
> if (return_code)
> *return_code = CXL_MBOX_CMD_RC_INPUT;
>
> + if (feat_data_size > U16_MAX - offset)
> + return -EINVAL;
> +
[Severity: Medium]
Does this bounds check in cxl_set_feature() have the same off-by-one issue
restricting access to the last byte of the feature space?
> struct cxl_mbox_set_feat_in *pi __free(kfree) =
> kzalloc(cxl_mbox->payload_size, GFP_KERNEL);
> if (!pi)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260813034538.13189-1-icheng@nvidia.com?part=1
next prev parent reply other threads:[~2026-08-13 3:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 3:45 [PATCH v5 0/7] cxl: Sashiko bug fixes Richard Cheng
2026-08-13 3:45 ` [PATCH v5 1/7] cxl/features: Reject feature offset that overflows 16-bit field Richard Cheng
2026-08-13 3:57 ` sashiko-bot [this message]
2026-08-13 3:45 ` [PATCH v5 2/7] cxl/region: Scan all partitions for unmapped poison Richard Cheng
2026-08-13 3:45 ` [PATCH v5 3/7] cxl/region: Don't leak tolerated RAM -EFAULT from unmapped poison scan Richard Cheng
2026-08-13 3:58 ` sashiko-bot
2026-08-13 3:45 ` [PATCH v5 4/7] cxl/region: Start unmapped poison scan at the committed decoder boundary Richard Cheng
2026-08-13 3:55 ` sashiko-bot
2026-08-13 3:45 ` [PATCH v5 5/7] cxl/memdev: Don't overwrite the error from an earlier partition poison query Richard Cheng
2026-08-13 4:01 ` sashiko-bot
2026-08-13 3:45 ` [PATCH v5 6/7] cxl/region: Reject poison scan for decoder without a partition Richard Cheng
2026-08-13 3:56 ` sashiko-bot
2026-08-13 3:45 ` [PATCH v5 7/7] cxl/fwctl: Propagate feature RPC delivery errors 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=20260813035701.B628E1F000E9@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.