[PATCH] cxl/mbox: Add the CXL 4.0 command return codes 001Fh and 0020h

[PATCH] cxl/mbox: Add the CXL 4.0 command return codes 001Fh and 0020h

[Gaobin Huang]

CMD_CMD_RC_TABLE ends at 001Eh (Invalid Extent List), but the command
return code table in CXL r4.0 Table 8-208 also defines:

  001Fh  Transfer Out of Order: The input parameters data transfer was
         aborted because it occurred out of order.
  0020h  Request Abort Not Supported by Background Operation: The ongoing
         background operation does not support the Request Abort command.

A device that reports either code is described as an unknown return code.
Add both entries, mapped to -ENXIO.

Signed-off-by: Gaobin Huang <huanggaobin23@semi.ac.cn>
---
 drivers/cxl/cxlmem.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
index c401e3a1a..43f29564c 100644
--- a/drivers/cxl/cxlmem.h
+++ b/drivers/cxl/cxlmem.h
@@ -190,6 +190,8 @@ static inline struct cxl_ep *cxl_ep_load(struct cxl_port *port,
 	C(FEATURETRANSFEROOO, -ENXIO, "feature transfer out of order"),		\
 	C(RESOURCEEXHAUSTED, -ENXIO, "resources are exhausted"),		\
 	C(EXTLIST, -ENXIO, "invalid Extent List"),				\
+	C(TRANSFEROOO, -ENXIO, "transfer out of order"),			\
+	C(REQABORTNOTSUP, -ENXIO, "request abort not supported"),		\
 
 #undef C
 #define C(a, b, c) CXL_MBOX_CMD_RC_##a

base-commit: 999811aca000b0d3d1c838c60dc9db7c72eb0c73
-- 
2.34.1

Re: [PATCH] cxl/mbox: Add the CXL 4.0 command return codes 001Fh and 0020h

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] cxl: OOB array access when parsing hardware return_code
--

commit 15edb1196288251867601cc5b50acf1789f0b357
Author: Gaobin Huang <huanggaobin23@semi.ac.cn>

cxl/mbox: Add the CXL 4.0 command return codes 001Fh and 0020h

This commit adds two new command return codes (001Fh and 0020h) from the CXL
r4.0 specification to the command return code table. A device reporting
either code was previously described as an unknown return code, and both are
now mapped to -ENXIO.

> diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
> index c401e3a1af06f..43f29564c1050 100644
> --- a/drivers/cxl/cxlmem.h
> +++ b/drivers/cxl/cxlmem.h
> @@ -190,6 +190,8 @@ static inline struct cxl_ep *cxl_ep_load(struct cxl_port *port,
>  	C(FEATURETRANSFEROOO, -ENXIO, "feature transfer out of order"),		\
>  	C(RESOURCEEXHAUSTED, -ENXIO, "resources are exhausted"),		\
>  	C(EXTLIST, -ENXIO, "invalid Extent List"),				\
> +	C(TRANSFEROOO, -ENXIO, "transfer out of order"),			\
> +	C(REQABORTNOTSUP, -ENXIO, "request abort not supported"),		\
>  
>  #undef C
>  #define C(a, b, c) CXL_MBOX_CMD_RC_##a

[Severity: High]
Does this code overflow the cxl_mbox_cmd_rctable[] array if the hardware
returns an unknown code?

Since the return code is read directly from the hardware mailbox status
register:

drivers/cxl/pci.c:__cxl_pci_mbox_send_cmd()
	status_reg = readq(cxlds->regs.mbox + CXLDEV_MBOX_STATUS_OFFSET);
	mbox_cmd->return_code =
		FIELD_GET(CXLDEV_MBOX_STATUS_RET_CODE_MASK, status_reg);

Could a buggy or malicious CXL device return a 16-bit value that exceeds the
size of cxl_mbox_cmd_rctable[]?

When cxl_mbox_cmd_rc2str() or cxl_mbox_cmd_rc2errno() uses this untrusted
return code as an array index:

drivers/cxl/cxlmem.h:cxl_mbox_cmd_rc2str()
static inline const char *cxl_mbox_cmd_rc2str(struct cxl_mbox_cmd *mbox_cmd)
{
	return cxl_mbox_cmd_rctable[mbox_cmd->return_code].desc;
}

Could this result in an out-of-bounds access that crashes the kernel when
attempting to dereference the garbage .desc pointer, or return a garbage .err
value?

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

Re: [PATCH] cxl/mbox: Add the CXL 4.0 command return codes 001Fh and 0020h

[Richard Cheng]

On Thu, Oct 15, 2026 at 01:50:48PM +0800, Gaobin Huang wrote:
> CMD_CMD_RC_TABLE ends at 001Eh (Invalid Extent List), but the command
> return code table in CXL r4.0 Table 8-208 also defines:
> 
>   001Fh  Transfer Out of Order: The input parameters data transfer was
>          aborted because it occurred out of order.
>   0020h  Request Abort Not Supported by Background Operation: The ongoing
>          background operation does not support the Request Abort command.
> 
> A device that reports either code is described as an unknown return code.
> Add both entries, mapped to -ENXIO.
> 
> Signed-off-by: Gaobin Huang <huanggaobin23@semi.ac.cn>
> ---
>  drivers/cxl/cxlmem.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
> index c401e3a1a..43f29564c 100644
> --- a/drivers/cxl/cxlmem.h
> +++ b/drivers/cxl/cxlmem.h
> @@ -190,6 +190,8 @@ static inline struct cxl_ep *cxl_ep_load(struct cxl_port *port,
>  	C(FEATURETRANSFEROOO, -ENXIO, "feature transfer out of order"),		\
>  	C(RESOURCEEXHAUSTED, -ENXIO, "resources are exhausted"),		\
>  	C(EXTLIST, -ENXIO, "invalid Extent List"),				\
> +	C(TRANSFEROOO, -ENXIO, "transfer out of order"),			\
> +	C(REQABORTNOTSUP, -ENXIO, "request abort not supported"),		\

Hi Gaobin,

Do we have users for them ? or potential users ?

Best regards,
Richard Cheng.

>  
>  #undef C
>  #define C(a, b, c) CXL_MBOX_CMD_RC_##a
> 
> base-commit: 999811aca000b0d3d1c838c60dc9db7c72eb0c73
> -- 
> 2.34.1
> 

Re: Re: [PATCH] cxl/mbox: Add the CXL 4.0 command return codes 001Fh and 0020h

[黄高彬]

Hi Richard,

> Do we have users for them ? or potential users ?

I checked the related code, and the honest answer is no for both today.

001Fh is the code Perform Maintenance (opcode 0600h) returns when the input
parameters are transferred in parts and the parts arrive out of order --
Action = Initiate Transfer, Continue Transfer, End Transfer (CXL r4.0,
8.2.10.7).  Linux does issue Perform Maintenance: PPR and the sparing
operations in edac.c both go through cxl_perform_maintenance().  That helper
always transfers the parameters in a single command though -- it returns
-ENOMEM when they do not fit in the mailbox payload instead of chunking --
so the ordering condition cannot arise from the driver.  The multi-chunk
flow in the specification is described for the Built-In Self-Test test
parameters, and there is no BIST support in the driver.

0020h is only the return code of Request Abort Background Operation (opcode
0005h).  Linux does not issue that command either.

So neither code has a producer in the driver today.  Both are defined in the
command return code table (CXL r4.0 Table 8-208) that CMD_CMD_RC_TABLE
transcribes, and carrying them costs two lines and no behavior change: a
device that reports either already comes back as -ENXIO through the
unknown-code path, so what the entries buy is a name instead of "unknown
return code".

If the point is that a definition should arrive with the code that can
produce it, that is a fair position too.  I can withdraw this patch and
resend it together with chunked maintenance transfer support, or with abort
support, whichever is implemented first. 

Thanks,
Gaobin

Re: [PATCH] cxl/mbox: Add the CXL 4.0 command return codes 001Fh and 0020h

[Dave Jiang]

On 10/15/26 1:42 AM, 黄高彬 wrote:
> Hi Richard,
> 
>> Do we have users for them ? or potential users ?
> 
> I checked the related code, and the honest answer is no for both today.
> 
> 001Fh is the code Perform Maintenance (opcode 0600h) returns when the input
> parameters are transferred in parts and the parts arrive out of order --
> Action = Initiate Transfer, Continue Transfer, End Transfer (CXL r4.0,
> 8.2.10.7).  Linux does issue Perform Maintenance: PPR and the sparing
> operations in edac.c both go through cxl_perform_maintenance().  That helper
> always transfers the parameters in a single command though -- it returns
> -ENOMEM when they do not fit in the mailbox payload instead of chunking --
> so the ordering condition cannot arise from the driver.  The multi-chunk
> flow in the specification is described for the Built-In Self-Test test
> parameters, and there is no BIST support in the driver.
> 
> 0020h is only the return code of Request Abort Background Operation (opcode
> 0005h).  Linux does not issue that command either.
> 
> So neither code has a producer in the driver today.  Both are defined in the
> command return code table (CXL r4.0 Table 8-208) that CMD_CMD_RC_TABLE
> transcribes, and carrying them costs two lines and no behavior change: a
> device that reports either already comes back as -ENXIO through the
> unknown-code path, so what the entries buy is a name instead of "unknown
> return code".
> 
> If the point is that a definition should arrive with the code that can
> produce it, that is a fair position too.  I can withdraw this patch and
> resend it together with chunked maintenance transfer support, or with abort
> support, whichever is implemented first. 

Yes lets do that.
> 
> Thanks,
> Gaobin