Re: [PATCH] cxl/mbox: Break poison list loop on an empty payload

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Out-of-bounds read of kernel memory due to unvalidated `po->count` from device payload.
--

--- Patch [1]: [PATCH] cxl/mbox: Break poison list loop on an empty payload ---
commit bae9e2badcecd54aec9a327464ba99a57b005a54
Author: Dave Jiang <dave.jiang@intel.com>
cxl/mbox: Break poison list loop on an empty payload

This commit prevents an infinite loop when a device returns count == 0
with CXL_POISON_FLAG_MORE set by breaking the poison list loop on an
empty payload.

Link: https://sashiko.dev/#/patchset/20260702090849.47501-1-icheng@nvidia.com?part=3

> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> --- a/drivers/cxl/core/mbox.c
> +++ b/drivers/cxl/core/mbox.c
[ ... ]
> @@ -1455,6 +1455,11 @@ int cxl_mem_get_poison(struct cxl_memdev *cxlmd, u64 offset, u64 len,
>  		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],

[Severity: High]
This is a pre-existing issue, but does this loop blindly trust the device
provided count without validating it against the actual payload size?

If a malicious or malfunctioning device returns a small payload but
specifies a large po->count, iterating up to le16_to_cpu(po->count) could
read out of bounds of the allocated cxl_mbox->payload_size. The
unvalidated memory is then passed to trace_cxl_poison().

Could we add a bounds check in cxl_mem_get_poison() to ensure the payload
actually contains the expected number of records?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709155714.1893280-1-dave.jiang@intel.com?part=1