Re: [PATCH v6 2/7] cxl/region: Scan all partitions for unmapped poison

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing bounds check on hardware-supplied `po->count` in `cxl_mem_get_poison` leads to out-of-bounds read of kernel memory.
--

commit f52d52e430dd176144d958a0ce4c3eb954ee8a23
Author: Richard Cheng <icheng@nvidia.com>

cxl/region: Scan all partitions for unmapped poison

cxl_get_poison_unmapped() sweeps the unmapped tail of each partition
from ctx->part onward. A fully-mapped partition has no unmapped tail,
it's a normal per-partition state, but the loop treated it with break,
aborting the whole sweep and silently skipping unmapped poison in all
later partition. Use continue so a fully-mapped partition is skipped and
later partitions are still scanned.

> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> index 27e63e6dab7c8..b03f30c04d350 100644
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c
> @@ -2928,7 +2928,7 @@ static int cxl_get_poison_unmapped(struct cxl_memdev *cxlmd,
>  			offset = res->start;
>  		length = res->end - offset + 1;
>  		if (!length)
> -			break;
> +			continue;
>  		rc = cxl_mem_get_poison(cxlmd, offset, length, NULL);

[Severity: High]
This is a pre-existing issue, but I noticed a potential out-of-bounds read in
cxl_mem_get_poison() when it processes the hardware-supplied poison records.

Looking at cxl_mem_get_poison() in drivers/cxl/core/mbox.c, the function
uses an untrusted hardware value po->count in the loop:

	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);

Could a buggy or malicious CXL device return an arbitrarily large po->count
value (for example 0xFFFF) that doesn't fit within the returned payload size
or the dynamically allocated mds->poison.list_out buffer?

If this happens, does this loop read past the end of the allocated memory,
potentially causing a kernel panic or information leak via ftrace?

>  		if (rc == -EFAULT && cxlds->part[i].mode == CXL_PARTMODE_RAM)
>  			continue;

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