From: Alison Schofield <alison.schofield@intel.com>
To: Guixin Liu <kanie@linux.alibaba.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
Jonathan Cameron <jic23@kernel.org>,
Dave Jiang <dave.jiang@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Dan Williams <djbw@kernel.org>, Ira Weiny <iweiny@kernel.org>,
Li Ming <ming.li@zohomail.com>, <linux-cxl@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] cxl/cdat: Fix uninitialized stack use in bandwidth gathering
Date: Thu, 27 Aug 2026 17:49:47 -0700 [thread overview]
Message-ID: <apDbK_xjfHEV69Cp@aschofie-mobl2.lan> (raw)
In-Reply-To: <20260812083035.372308-2-kanie@linux.alibaba.com>
On Wed, Aug 12, 2026 at 04:30:34PM +0800, Guixin Liu wrote:
> cxl_endpoint_gather_bandwidth() declares three access_coordinate arrays on
> the stack - pci_coord, sw_coord and ep_coord - without initializing them,
> and relies on its helpers to fill every member. None of them does.
> cxl_pci_get_bandwidth() and cxl_port_get_switch_dport_bandwidth() assign
> only read_bandwidth and write_bandwidth, and __cxl_coordinates_combine()
> assigns an output bandwidth only when both input bandwidths are non-zero.
> Every member a producer declines to set is read back as whatever was on the
> stack. cxl_switch_gather_bandwidth() has the same defect in its coords
> array, which it hands to cxl_pci_get_bandwidth() and then to
> cxl_coordinates_combine().
>
> Both cases occur on real topologies. The latency members are never written
> by any of those producers, yet __cxl_coordinates_combine() sums them
> unconditionally, so the latency reads are undefined on every call. And a
> device whose CDAT DSLBIS reports no bandwidth for an access class leaves
> perf->cdat_coord zero for that class, which is exactly the condition that
> makes __cxl_coordinates_combine() skip the bandwidth assignment and leave
> the ep_coord entry untouched.
>
> The ep_coord case escapes the function: cxl_bandwidth_add() accumulates it
> into the per-upstream-port aggregate that is published through the region's
> access coordinate sysfs attributes, so stack contents are reported to
> userspace as a bandwidth figure. The latency sums are discarded by
> cxl_bandwidth_add() rather than published, but they are still computed from
> uninitialized memory.
>
> Zero initialize the four arrays. Zero is already the value this code uses
> for "not reported" - both the __cxl_coordinates_combine() guard and
> coordinates_valid() test for it - so a member no producer sets now reads
> back as unknown rather than as a plausible number.
Hi Guixin Liu,
Please see my comments on the einj_inject patch about commit message
clarity and level of detail. The same issue applies here.
https://lore.kernel.org/linux-cxl/apDXSzSZVcjQ027J@aschofie-mobl2.lan/
For this patch, I think the essential story is:
Background:
cxl_endpoint_get_perf_coordinates() returns success for RCDs without
calculating coordinates.
Issue:
The output array is left uninitialized on that path.
Impact:
Callers can consume and expose garbage access-coordinate values.
Resolution:
Initialize the coordinates to zero before returning for an RCD.
That is enough to explain why the patch is needed. I do not need the
full path through CDAT parsing, __cxl_coordinates_combine(), QoS class
selection, cxl_dpa_perf, and sysfs to understand the bug.
Also, as with the other patch, please say how this was found and how it
was tested.
-- Alison
>
> Fixes: a5ab0de0ebaa ("cxl: Calculate region bandwidth of targets with shared upstream link")
> Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
> ---
> drivers/cxl/core/cdat.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cxl/core/cdat.c b/drivers/cxl/core/cdat.c
> index 5c9f07262513..df9261ba84e5 100644
> --- a/drivers/cxl/core/cdat.c
> +++ b/drivers/cxl/core/cdat.c
> @@ -633,9 +633,9 @@ static int cxl_endpoint_gather_bandwidth(struct cxl_region *cxlr,
> struct cxl_port *endpoint = to_cxl_port(cxled->cxld.dev.parent);
> struct cxl_port *parent_port = to_cxl_port(endpoint->dev.parent);
> struct cxl_port *gp_port = to_cxl_port(parent_port->dev.parent);
> - struct access_coordinate pci_coord[ACCESS_COORDINATE_MAX];
> - struct access_coordinate sw_coord[ACCESS_COORDINATE_MAX];
> - struct access_coordinate ep_coord[ACCESS_COORDINATE_MAX];
> + struct access_coordinate pci_coord[ACCESS_COORDINATE_MAX] = { };
> + struct access_coordinate sw_coord[ACCESS_COORDINATE_MAX] = { };
> + struct access_coordinate ep_coord[ACCESS_COORDINATE_MAX] = { };
> struct cxl_memdev *cxlmd = cxled_to_memdev(cxled);
> struct cxl_dev_state *cxlds = cxlmd->cxlds;
> struct pci_dev *pdev = to_pci_dev(cxlds->dev);
> @@ -757,7 +757,7 @@ static struct xarray *cxl_switch_gather_bandwidth(struct cxl_region *cxlr,
> {
> struct xarray *res_xa __free(free_perf_xa) =
> kzalloc_obj(*res_xa);
> - struct access_coordinate coords[ACCESS_COORDINATE_MAX];
> + struct access_coordinate coords[ACCESS_COORDINATE_MAX] = { };
> struct cxl_perf_ctx *ctx, *us_ctx;
> unsigned long index, us_index;
> int dev_count = 0;
> --
> 2.43.7
>
next prev parent reply other threads:[~2026-08-28 0:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 8:30 [PATCH v3 0/2] cxl: Fix uninitialized access coordinates Guixin Liu
2026-08-12 8:30 ` [PATCH v3 1/2] cxl/cdat: Fix uninitialized stack use in bandwidth gathering Guixin Liu
2026-08-12 8:44 ` sashiko-bot
2026-08-12 9:08 ` Guixin Liu
2026-08-28 0:49 ` Alison Schofield [this message]
2026-08-28 0:55 ` Alison Schofield
2026-08-31 7:00 ` Guixin Liu
2026-08-12 8:30 ` [PATCH v3 2/2] cxl/port: Fix uninitialized coordinates reported for RCDs Guixin Liu
2026-08-12 9:48 ` [PATCH v3 0/2] cxl: Fix uninitialized access coordinates 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=apDbK_xjfHEV69Cp@aschofie-mobl2.lan \
--to=alison.schofield@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=djbw@kernel.org \
--cc=iweiny@kernel.org \
--cc=jic23@kernel.org \
--cc=kanie@linux.alibaba.com \
--cc=linux-cxl@vger.kernel.org \
--cc=ming.li@zohomail.com \
--cc=vishal.l.verma@intel.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.