Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: lirongqing <lirongqing@baidu.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH] RDMA/mlx5: Check SIG_ERR CQE mkey lookup before dereferencing
Date: Sat, 19 Sep 2026 10:17:00 +0000	[thread overview]
Message-ID: <20260919101701.1241C1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260919100806.2320-1-lirongqing@baidu.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] rdma/mlx5: un-ratelimited warning in CQ polling loop causes log flood
--

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

RDMA/mlx5: Check SIG_ERR CQE mkey lookup before dereferencing

This commit adds a NULL check after looking up a signature context in
mlx5_poll_one() to prevent a crash when a memory region is concurrently
deregistered. If the lookup fails, it drops the lock, logs a warning, and
fetches the next completion.

> diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
> index 49b4bf148a4a0..b0b1177077aa0 100644
> --- a/drivers/infiniband/hw/mlx5/cq.c
> +++ b/drivers/infiniband/hw/mlx5/cq.c
> @@ -563,6 +563,13 @@ static int mlx5_poll_one(struct mlx5_ib_cq *cq,
>  		xa_lock(&dev->sig_mrs);
>  		sig = xa_load(&dev->sig_mrs,
>  				mlx5_base_mkey(be32_to_cpu(sig_err_cqe->mkey)));
> +		if (!sig) {
> +			xa_unlock(&dev->sig_mrs);
> +			mlx5_ib_warn(dev, "CQN: 0x%x Got SIGERR on unknown mkey: 0x%x\n",
> +				     cq->mcq.cqn,
> +				     be32_to_cpu(sig_err_cqe->mkey));
> +			goto repoll;

[Severity: Medium]
Could this un-ratelimited warning lead to console flooding and CPU soft
lockups?

A stream of MLX5_CQE_SIG_ERR completions with unknown mkeys (which can be
triggered by remote peers sending invalid data to a registered memory region)
causes mlx5_poll_one() to repeatedly call mlx5_ib_warn() and jump to the
repoll label.

Because goto repoll fetches the next completion queue entry without returning,
it bypasses the CQ polling budget entirely. This could allow a remote attacker
to intentionally stream invalid packets to flood the queue, weaponizing the
loop into a denial of service vector.

Should this use a ratelimited print, and possibly avoid bypassing the polling
budget?

> +		}
>  		get_sig_err_item(sig_err_cqe, &sig->err_item);
>  		sig->sig_err_exists = true;
>  		sig->sigerr_count++;

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

  reply	other threads:[~2026-09-19 10:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-19 10:08 [PATCH] RDMA/mlx5: Check SIG_ERR CQE mkey lookup before dereferencing lirongqing
2026-09-19 10:17 ` sashiko-bot [this message]
2026-09-28 18:38 ` Leon Romanovsky
2026-09-29  1:21   ` 答复: [????] " Li,Rongqing

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=20260919101701.1241C1F000FF@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