From: sashiko-bot@kernel.org
To: lirongqing <lirongqing@baidu.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH v2] RDMA/mlx5: Fix destination index when resizing a CQ
Date: Wed, 30 Sep 2026 01:17:23 +0000 [thread overview]
Message-ID: <20260930011723.D89A41F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260930010630.2797-1-lirongqing@baidu.com>
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
prev parent reply other threads:[~2026-09-30 1:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 1:06 [PATCH v2] RDMA/mlx5: Fix destination index when resizing a CQ lirongqing
2026-09-30 1:17 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260930011723.D89A41F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lirongqing@baidu.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox