All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.