[PATCH v2] RDMA/mlx5: Fix destination index when resizing a CQ

[PATCH v2] RDMA/mlx5: Fix destination index when resizing a CQ

[lirongqing]

From: Li RongQing <lirongqing@baidu.com>

copy_resize_cqes() uses the absolute consumer index to copy pending
CQEs into the resized CQ buffer. The destination slot must wrap at
resize_buf->nent, but the code applies a bitwise AND with nent itself.

CQ sizes are rounded up to a power of two, so nent has only one bit
set. Masking with nent therefore produces either zero or nent instead
of an index in the range [0, nent). When it produces nent,
mlx5_frag_buf_get_wqe() accesses one entry beyond the resized CQ buffer
and the following memcpy() can corrupt memory.

Use modulo nent to calculate the destination slot and keep it within
the resized CQ.

Fixes: bde51583f49b ("IB/mlx5: Add support for resize CQ")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
Diff with v1: replace & with %

 drivers/infiniband/hw/mlx5/cq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index dc457fa..fc4ee1c 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -1319,7 +1319,7 @@ static int copy_resize_cqes(struct mlx5_ib_cq *cq)
 
 	while (get_cqe_opcode(scqe64) != MLX5_CQE_RESIZE_CQ) {
 		dcqe = mlx5_frag_buf_get_wqe(&cq->resize_buf->fbc,
-					     (i + 1) & cq->resize_buf->nent);
+					     (i + 1) % cq->resize_buf->nent);
 		dcqe64 = dsize == 64 ? dcqe : dcqe + 64;
 		sw_own = sw_ownership_bit(i + 1, cq->resize_buf->nent);
 		memcpy(dcqe, scqe, dsize);
-- 
2.9.4

Re: [PATCH v2] RDMA/mlx5: Fix destination index when resizing a CQ

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] rdma: mlx5: OOB write in copy_resize_cqes() via negative signed modulo
--

commit 0306cc5acf75dd86ce62818b27d260ae4841d2e6
Author: Li RongQing <lirongqing@baidu.com>

RDMA/mlx5: Fix destination index when resizing a CQ

This commit fixes the destination index calculation when resizing a CQ in the
mlx5 driver. It replaces a bitwise AND with a modulo operation to ensure the
destination slot remains within the resized CQ buffer.

> diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
> index 072b77a2c8a6c..928330f8a6dab 100644
> --- a/drivers/infiniband/hw/mlx5/cq.c
> +++ b/drivers/infiniband/hw/mlx5/cq.c
> @@ -1313,7 +1313,7 @@ static int copy_resize_cqes(struct mlx5_ib_cq *cq)
>  
>  	while (get_cqe_opcode(scqe64) != MLX5_CQE_RESIZE_CQ) {
>  		dcqe = mlx5_frag_buf_get_wqe(&cq->resize_buf->fbc,
> -					     (i + 1) & cq->resize_buf->nent);
> +					     (i + 1) % cq->resize_buf->nent);
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Critical]
Could this result in an out-of-bounds write?

In copy_resize_cqes(), i is an int assigned from the u32 counter
cq->mcq.cons_index. On high-throughput networks, cons_index can exceed
INT_MAX, causing i to become negative.

When i + 1 is negative, the signed modulo operation yields a negative
remainder. This negative value is passed to mlx5_frag_buf_get_wqe(), where it
is implicitly cast to u32 ix:

include/linux/mlx5/driver.h:mlx5_frag_buf_get_wqe() {
    ...
    frag = ix >> fbc->log_frag_strides;

    return fbc->frags[frag].buf + ((fbc->frag_sz_m1 & ix) << fbc->log_stride);
}

This cast results in a massive unsigned value, leading to an out-of-bounds
pointer for dcqe. The subsequent memcpy(dcqe, scqe, dsize) would then
corrupt kernel memory.

>  		dcqe64 = dsize == 64 ? dcqe : dcqe + 64;
>  		sw_own = sw_ownership_bit(i + 1, cq->resize_buf->nent);
>  		memcpy(dcqe, scqe, dsize);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930010630.2797-1-lirongqing@baidu.com?part=1