Re: [PATCH v6 5/7] cxl/memdev: Don't overwrite the error from an earlier partition poison query

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Unvalidated `po->count` from hardware payload causes an out-of-bounds memory read that gets exposed to userspace via the `cxl_poison` tracepoint.
--

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

cxl/memdev: Don't overwrite the error from an earlier partition poison query

cxl_get_poison_by_memdev() queries Get Poison List per partition but
never checks the result inside the loop, so a later partition's success
overwrites an earlier partition's failure and the whole scan reports
success while that partition's poison went unlisted. Before the loop
conversion the PMEM query returned early on error. Stop the loop on any
error not already tolerated as a RAM -EFAULT.

> diff --git a/drivers/cxl/core/memdev.c b/drivers/cxl/core/memdev.c
> index b3419df586b9c..e39b3d13fd566 100644
> --- a/drivers/cxl/core/memdev.c
> +++ b/drivers/cxl/core/memdev.c
> @@ -231,6 +231,8 @@ static int cxl_get_poison_by_memdev(struct cxl_memdev *cxlmd)
>  		 */
>  		if (rc == -EFAULT && cxlds->part[i].mode == CXL_PARTMODE_RAM)
>  			rc = 0;
> +		if (rc)
> +			break;
>  	}
>  	return rc;
>  }

[Severity: High]
This is a pre-existing issue, but I noticed a potential out-of-bounds read
triggered when cxl_get_poison_by_memdev() calls cxl_mem_get_poison() earlier
in this loop.

Looking at cxl_mem_get_poison() in drivers/cxl/core/mbox.c:

drivers/cxl/core/mbox.c:cxl_mem_get_poison() {
    ...
		rc = cxl_internal_send_cmd(cxl_mbox, &mbox_cmd);
		if (rc)
			break;

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

Does this code trust the unvalidated po->count value from the hardware
payload?

If a device returns an artificially large po->count (up to 65535), the loop
appears to read beyond the bounds of the mds->poison.list_out buffer and expose
adjacent kernel memory to userspace via the cxl_poison tracepoint.

Could we bound po->count to mbox_cmd.size_out or the buffer capacity
to prevent this?

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