All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Youngsung Ahn" <ays511.kr@gmail.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH v2] RDMA/rxe: validate cur_sge on the receive path before indexing dma->sge[]
Date: Thu, 01 Oct 2026 15:42:36 +0000	[thread overview]
Message-ID: <20261001154237.254481F00899@smtp.kernel.org> (raw)
In-Reply-To: <20261001152345.3259024-1-ays511.kr@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] RDMA/rxe: double-fetch TOCTOU vulnerability in copy_data() bounds check
--

commit 2fd3d60fe5490f46cfcd1b0614c53c62687fc767
Author: Youngsung Ahn <ays511.kr@gmail.com>

RDMA/rxe: validate cur_sge on the receive path before indexing dma->sge[]

This commit adds bounds validation for cur_sge in copy_data() on the receive
path before the scatter/gather array is accessed. It intends to reject an
out-of-range cur_sge to prevent denial of service or information leaks.

> diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c
> index 2afda5154dfb9..0c510bb7ae2a7 100644
> --- a/drivers/infiniband/sw/rxe/rxe_mr.c
> +++ b/drivers/infiniband/sw/rxe/rxe_mr.c
> @@ -436,6 +436,11 @@ int copy_data(
>  		goto err2;
>  	}
>  
> +	if (unlikely(dma->cur_sge >= dma->num_sge)) {

[Severity: High]
Since dma can point directly into an attacker-controlled mmap'd ring buffer,
could this introduce a double-fetch vulnerability?

For example, on the send path, a WQE is retrieved without a kernel copy and
passed along:

rxe_requester()
   finish_packet()
       copy_data(..., &wqe->dma, ...)

Earlier in copy_data(), sge is initialized by fetching dma->cur_sge:

	struct rxe_sge *sge = &dma->sge[dma->cur_sge];

Because the check added here lacks READ_ONCE(), the compiler could fetch
dma->cur_sge twice from shared memory.

A malicious thread might race to provide an out-of-bounds value for the first
fetch, followed by a valid value for this second fetch. This would bypass the
check and result in an out-of-bounds dereference when sge->length is evaluated
shortly after.

Would caching dma->cur_sge locally with READ_ONCE() prevent this?

> +		err = -EINVAL;
> +		goto err2;
> +	}
> +
>  	if (sge->length && (offset < sge->length)) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001152345.3259024-1-ays511.kr@gmail.com?part=1

      reply	other threads:[~2026-10-01 15:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30 18:01 [PATCH] RDMA/rxe: validate cur_sge on the receive path before indexing dma->sge[] Youngsung Ahn
2026-09-30 18:11 ` sashiko-bot
2026-10-01 15:23 ` [PATCH v2] " Youngsung Ahn
2026-10-01 15:42   ` 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=20261001154237.254481F00899@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ays511.kr@gmail.com \
    --cc=linux-rdma@vger.kernel.org \
    --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.