Re: [PATCH] cxl/mbox: bound the device-supplied command return code

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] cxl: incorrect comment about return code mappings
--

commit 2dcefe093dad494dcbd18a284c00e32e26f8041e
Author: Gaobin Huang <huanggaobin23@semi.ac.cn>

cxl/mbox: bound the device-supplied command return code

Validates the device-supplied command return code from the mailbox status
register before indexing the command return code table. This prevents an
out-of-bounds read if a device reports an undefined code.

> diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
> index c401e3a1af06f..7f89dc4fcf050 100644
> --- a/drivers/cxl/cxlmem.h
> +++ b/drivers/cxl/cxlmem.h

[ ... ]

>  static inline int cxl_mbox_cmd_rc2errno(struct cxl_mbox_cmd *mbox_cmd)
>  {
> -	return cxl_mbox_cmd_rctable[mbox_cmd->return_code].err;
> +	const struct cxl_mbox_cmd_rc *rc = cxl_mbox_cmd_rc_entry(mbox_cmd);
> +
> +	/*
> +	 * Unknown codes are still failures, and -ENXIO is what every
> +	 * non-success entry in the table maps to, so the caller cannot tell
> +	 * an undefined code from a defined error in a way that matters.
> +	 */

[Severity: Low]
This isn't a bug, but in cxl_mbox_cmd_rc2errno(), is this comment accurate
regarding the table mappings?

While most non-success entries map to -ENXIO, PADDR maps to -EFAULT and
POISONLMT maps to -EBUSY. The fallback to -ENXIO is safe, but the comment
and the commit message claim that every non-success entry maps to -ENXIO,
which could be confusing.

> +	return rc ? rc->err : -ENXIO;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929060747.3550005-1-huanggaobin23@semi.ac.cn?part=1