All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Anisa Su" <anisa.su887@gmail.com>
Cc: nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org
Subject: Re: [PATCH v12 7/8] cxl/core: Return endpoint decoder information from region search
Date: Fri, 31 Jul 2026 09:01:21 +0000	[thread overview]
Message-ID: <20260731090122.1E07D1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260731084901.1512819-8-anisa.su@samsung.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `cxled` out-parameter is left uninitialized on early return paths in `cxl_dpa_to_region` and its inline stub, creating a vulnerability for uninitialized variable usage.
--

--- Patch [7]: [PATCH v12 7/8] cxl/core: Return endpoint decoder information from region search ---
commit c2b37a56d99a44aee4d4340c7154d9180c620839
Author: Ira Weiny <iweiny@kernel.org>

cxl/core: Return endpoint decoder information from region search

This commit updates cxl_dpa_to_region() to return the endpoint decoder
found during the region search via a new out-parameter. This information
is needed for dynamic capacity extent processing to calculate HPA offsets.

> diff --git a/drivers/cxl/core/core.h b/drivers/cxl/core/core.h
> index 07555ae638594..e4bd220faa92c 100644
> --- a/drivers/cxl/core/core.h
> +++ b/drivers/cxl/core/core.h
[ ... ]
> @@ -61,7 +62,8 @@ static inline u64 cxl_dpa_to_hpa(struct cxl_region *cxlr,
>  	return ULLONG_MAX;
>  }
>  static inline
> -struct cxl_region *cxl_dpa_to_region(const struct cxl_memdev *cxlmd, u64 dpa)
> +struct cxl_region *cxl_dpa_to_region(const struct cxl_memdev *cxlmd, u64 dpa,
> +				     struct cxl_endpoint_decoder **cxled)
>  {
>  	return NULL;
>  }

[Severity: Medium]
If a future caller passes an uninitialized pointer variable for cxled, will
this static inline stub leave it uninitialized?

Could we set "*cxled = NULL" here when cxled is provided, to prevent callers
from evaluating stack garbage on return?

> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> index 1e211542b6b64..ec5e5b7090cf2 100644
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c
[ ... ]
> @@ -3045,11 +3046,13 @@ static int __cxl_dpa_to_region(struct device *dev, void *arg)
>  			dev_name(dev));
>  
>  	ctx->cxlr = cxlr;
> +	ctx->cxled = cxled;
>  
>  	return 1;
>  }
>  
> -struct cxl_region *cxl_dpa_to_region(const struct cxl_memdev *cxlmd, u64 dpa)
> +struct cxl_region *cxl_dpa_to_region(const struct cxl_memdev *cxlmd, u64 dpa,
> +				     struct cxl_endpoint_decoder **cxled)
>  {
>  	struct cxl_dpa_to_region_context ctx;
>  	struct cxl_port *port = cxlmd->endpoint;

[Severity: Medium]
Similar to the inline stub above, cxl_dpa_to_region() has an early return
path right after these variable declarations:

    if (!cxlmd->dev.driver)
        return NULL;

If a caller doesn't pre-initialize their cxled variable and hits this early
return, won't cxled remain uninitialized?

While current callers in this patch pass NULL, a future caller expecting
cxled to be populated might evaluate uninitialized stack memory. Should this
early return also initialize *cxled to NULL if cxled is provided?

> @@ -3063,6 +3066,9 @@ struct cxl_region *cxl_dpa_to_region(const struct cxl_memdev *cxlmd, u64 dpa)
>  	if (cxl_num_decoders_committed(port))
>  		device_for_each_child(&port->dev, &ctx, __cxl_dpa_to_region);
>  
> +	if (cxled)
> +		*cxled = ctx.cxled;
> +
>  	return ctx.cxlr;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731084901.1512819-1-anisa.su@samsung.com?part=7

  reply	other threads:[~2026-07-31  9:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31  8:48 [PATCH v12 0/8] DCD Prep Series Anisa Su
2026-07-31  8:48 ` [PATCH v12 1/8] cxl/mbox: Flag support for Dynamic Capacity Devices (DCD) Anisa Su
2026-07-31  8:48 ` [PATCH v12 2/8] cxl/mem: Read dynamic capacity configuration from the device Anisa Su
2026-07-31  9:01   ` sashiko-bot
2026-07-31  8:48 ` [PATCH v12 3/8] cxl/cdat: Gather DSMAS data for DCD partitions Anisa Su
2026-07-31  9:02   ` sashiko-bot
2026-07-31  8:48 ` [PATCH v12 4/8] cxl/events: Split event msgnum configuration from irq setup Anisa Su
2026-07-31  8:48 ` [PATCH v12 5/8] cxl/pci: Factor out interrupt policy check Anisa Su
2026-07-31  8:48 ` [PATCH v12 6/8] cxl/mem: Configure dynamic capacity interrupts Anisa Su
2026-07-31  9:04   ` sashiko-bot
2026-07-31  8:48 ` [PATCH v12 7/8] cxl/core: Return endpoint decoder information from region search Anisa Su
2026-07-31  9:01   ` sashiko-bot [this message]
2026-07-31  8:48 ` [PATCH v12 8/8] cxl/core: Enforce partition order/simplify partition calls Anisa Su

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=20260731090122.1E07D1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=anisa.su887@gmail.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --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.