From: Richard Cheng <icheng@nvidia.com>
To: Alison Schofield <alison.schofield@intel.com>
Cc: Zhenhao Wan <whi4ed0g@gmail.com>,
dave@stgolabs.net, jic23@kernel.org, dave.jiang@intel.com,
vishal.l.verma@intel.com, djbw@kernel.org,
danwilliams@nvidia.com, iweiny@kernel.org, ming.li@zohomail.com,
kobak@nvidia.com, kaihengf@nvidia.com, kees@kernel.org,
newtonl@nvidia.com, kristinc@nvidia.com, mochs@nvidia.com,
linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] cxl/features: Reject Get Feature count larger than the output buffer
Date: Fri, 26 Jun 2026 15:27:32 +0800 [thread overview]
Message-ID: <aj4pYfg51dWr__mw@MWDK4CY14F> (raw)
In-Reply-To: <ajxHwh3s2lM98aed@aschofie-mobl2.lan>
On Wed, Jun 24, 2026 at 02:10:26PM +0800, Alison Schofield wrote:
> On Wed, Jun 24, 2026 at 01:54:50PM -0700, Alison Schofield wrote:
> > On Wed, Jun 24, 2026 at 09:47:37PM +0800, Richard Cheng wrote:
> > > cxlctl_get_feature() sizes its output buffer from the user's
> > > fwctl_rpc.out_len, but the device is told to write
> > > cxl_mbox_get_feat_in.count bytes into rpc_out->payload, which is a
> > > separate user-controlled value. Nothing bounds count against out_len, so
> > > a small out_len with a large count overflows the kvzalloc()'d buffer.
> > > A heap OOB write reachable from FWCTL_RPC.
> > >
> > > Reject requests where count exceeds the available payload room, before
> > > allocating.
> > >
> > > Fixes: 5908f3ed6dc2 ("cxl: Add support to handle user feature commands for get feature")
> > > Reviewed-by: Kai-Heng Feng <kaihengf@nvidia.com>
> > > Reviewed-by: Koba Ko <kobak@nvidia.com>
> > > Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> > > Signed-off-by: Richard Cheng <icheng@nvidia.com>
> > > ---
> > > Changelog:
> > >
> > > v1 -> v2:
> > > - Drop the reproducer and trim the KASAN splat in the commit message
> > > - Sent the reproducer as a regression test in ndctl separately.
> >
> > This patch itself looks good. Looking at the other bounds checks
> > Sashiko suggests, I'd rather see this all fixed up in one patch or
> > patchset, rather than dribble in as multiple patches.
> >
> > Maybe it all fits into one patch, like this:
> > cxl/features; Add bounds checking for get/set feature commands
> > or maybe it works better as a set.
> >
> > Either way, doing in one swoop would be nice!
>
> Oh, seems I'm reading patches out of order.
>
> Now I see this:
> https://lore.kernel.org/linux-cxl/20260620-cxl-fwctl-oob-v1-1-5758e34d784a@gmail.com/
> which looks like it covers one of Sashikos's complaints.
>
Hi Alison,
Thanks for pointing this out.
Then that would be no problem for me, I'll append my fixes with Zhenhao's patch.
so my original fix + sashiko's complain about cxlctl_set_feature() and cxl_get_feature().
I'll put them in my work and send as a serie.
--Richard
> >
> > -- Alison
> >
> > >
> > > Best regards,
> > > Richard Cheng
> > > ---
> > > drivers/cxl/core/features.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/cxl/core/features.c b/drivers/cxl/core/features.c
> > > index 85185af46b72..9c714ee42a41 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);
> > > +
> > > struct fwctl_rpc_cxl_out *rpc_out __free(kvfree) =
> > > kvzalloc(out_size, GFP_KERNEL);
> > > if (!rpc_out)
> > >
> > > base-commit: ef0c9f75a19532d7675384708fc8621e10850104
> > > --
> > > 2.43.0
> > >
> >
next prev parent reply other threads:[~2026-06-26 7:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-24 13:47 [PATCH v2] cxl/features: Reject Get Feature count larger than the output buffer Richard Cheng
2026-06-24 14:05 ` sashiko-bot
2026-06-24 20:54 ` Alison Schofield
2026-06-24 21:10 ` Alison Schofield
2026-06-26 7:27 ` Richard Cheng [this message]
2026-06-26 16:17 ` Dave Jiang
2026-06-29 2:12 ` Richard Cheng
2026-06-29 15:37 ` Dave Jiang
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=aj4pYfg51dWr__mw@MWDK4CY14F \
--to=icheng@nvidia.com \
--cc=alison.schofield@intel.com \
--cc=danwilliams@nvidia.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=djbw@kernel.org \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=kaihengf@nvidia.com \
--cc=kees@kernel.org \
--cc=kobak@nvidia.com \
--cc=kristinc@nvidia.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.li@zohomail.com \
--cc=mochs@nvidia.com \
--cc=newtonl@nvidia.com \
--cc=vishal.l.verma@intel.com \
--cc=whi4ed0g@gmail.com \
/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.