Re: [PATCH v5 4/7] cxl/region: Start unmapped poison scan at the committed decoder boundary

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

Pre-existing issues:
- [High] Out-of-bounds read and information leak via hardware-supplied poison record count.
--

--- Patch [4]: [PATCH v5 4/7] cxl/region: Start unmapped poison scan at the committed decoder boundary ---
commit 7ebf989f20ca7ca7009f85db447392e5d1e320f2
Author: Richard Cheng <[email protected]>
Subject: cxl/region: Start unmapped poison scan at the committed decoder boundary

This commit fixes poison reporting for unmapped DPA ranges by resuming
the scan at the last committed decoder offset instead of skipping it.
It ensures poison in uncommitted decoder allocations is properly scanned
and reported.

> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c

[ ... ]

> @@ -2920,10 +2919,8 @@ static int cxl_get_poison_unmapped(struct cxl_memdev *cxlmd,
>  	 */
>  	for (int i = ctx->part; i < cxlds->nr_partitions; i++) {
>  		res = &cxlds->part[i].res;
> -		for (p = res->child, last = NULL; p; p = p->sibling)
> -			last = p;
> -		if (last)
> -			offset = last->end + 1;
> +		if (i == ctx->part)
> +			offset = ctx->offset;
>  		else
>  			offset = res->start;
>  		length = res->end - offset + 1;

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the subsequent
call to cxl_mem_get_poison(), I noticed a potential out-of-bounds read in
drivers/cxl/core/mbox.c.

Does cxl_mem_get_poison() properly bounds check the hardware-supplied
poison record count?

In drivers/cxl/core/mbox.c:cxl_mem_get_poison(), the loop blindly uses
po->count to iterate:

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

If a malicious or buggy CXL device returns a small payload
(e.g., meeting the 32-byte header min_out) but a large po->count
(e.g., 65535), the internal send command will succeed. 

Will this cause the loop to read past the end of the kvmalloc-backed
buffer and leak kernel memory into the ftrace ring buffer, or
potentially panic if it reaches an unmapped page?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4