Re: [PATCH v7 6/7] cxl/region: Reject poison scan for decoder without a partition

[sashiko-bot@kernel.org]

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

New issues:
- [Medium] Returning -ENODEV in poison_by_decoder() incorrectly aborts the iteration over the port's decoders, failing the entire poison scan.

Pre-existing issues:
- [High] The function `cxl_mem_get_poison` does not validate that the number of poison records returned by the device (`po->count`) fits within the allocated buffer, leading to an out-of-bounds read and information leak.
--

commit 38cab4750fe29ee2e45310ad8ff37111d581eb8d
Author: Richard Cheng <icheng@nvidia.com>
Subject: cxl/region: Reject poison scan for decoder without a partition

The __cxl_dpa_reserve() function may leave cxled->part at -1 when a
decoder's DPA range doesn't map to any reported partition. This commit
returns -ENODEV before accessing the partition array when no partition
was assigned.

> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> index b7dc5d4988da7..afe3fb57b7fe2 100644
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c
> @@ -2954,6 +2954,8 @@ static int poison_by_decoder(struct device *dev, void *arg)
>  	cxled = to_cxl_endpoint_decoder(dev);
>  	if (!cxled->dpa_res)
>  		return rc;
> +	if (cxled->part < 0)
> +		return -ENODEV;

[Severity: Medium]
Does returning -ENODEV in poison_by_decoder() incorrectly abort the iteration
over the port's decoders?

When a CXL port has an endpoint decoder that is not mapped to any partition,
the device_for_each_child() iteration will abort prematurely on the first
unmapped decoder. This prevents the remaining valid decoders from being
scanned for poison and skips cxl_get_poison_unmapped() entirely.

Could this return 0 instead to skip the unmapped decoder while allowing the
overall poison scan to continue?

This isn't a bug introduced by this patch, but I noticed another problem in
the cxl_mem_get_poison() function called later in this path:

drivers/cxl/core/mbox.c:cxl_mem_get_poison() {
    ...
		if (!le16_to_cpu(po->count)) {
			dev_dbg(&cxlmd->dev, "Poison empty payload!\n");
			break;
		}

		for (int i = 0; i < le16_to_cpu(po->count); i++)
			trace_cxl_poison(cxlmd, cxlr, &po->record[i],
					 po->flags, po->overflow_ts,
					 CXL_POISON_TRACE_LIST);
    ...
}

[Severity: High]
Does this code overflow po->record[] if a buggy or malicious CXL device
returns a large po->count value?

The po->count value from the device payload is used to index the array
without being validated against the size of the list_out buffer allocated
via kvmalloc. If the firmware returns a large count value alongside a
small actual payload size, this could lead to an out-of-bounds read.

Can this leak adjacent kernel memory to the ftrace ring buffer or trigger a
kernel oops if the read crosses into an unmapped page?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902053839.25595-1-icheng@nvidia.com?part=6