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

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

[AYS]

A user QP's receive queue is an mmap'd ring: the user provider writes the
WQEs and post_recv does not touch them, so every field of struct
rxe_recv_wqe is attacker controlled. When the responder takes a WQE it
validates only dma.num_sge (rxe_get_recv_wqe()/get_srq_wqe()); dma.cur_sge,
dma.sge_offset and dma.resid are copied into qp->resp.srq_wqe unchecked.

copy_data() then uses cur_sge as an index immediately --
struct rxe_sge *sge = &dma->sge[dma->cur_sge];
-- and dereferences it (sge->length) before the in-loop
"dma->cur_sge >= dma->num_sge" test, which only runs after the first sge++.
cur_sge is a u32, so this reads far out of bounds of the RXE_MAX_SGE-entry
dma->sge[] embedded in the kmalloc-2k struct rxe_qp: an information leak (the
out-of-bounds sge->length is recoverable through the work-completion status)
and a DoS. The send queue already got this check in commit 126c757e4cd4; the
receive path did not.

Reject an out-of-range cur_sge in copy_data() before the first sge
dereference. This also covers the send retry path and is harmless to the
kernel ULP path, which always sets cur_sge = 0.

Fixes: 8700e3e7c485 ("Soft RoCE driver")
Signed-off-by: Youngsung Ahn <ays511.kr@gmail.com>
---
Notes (not part of the commit):
Reproduced on a KASAN x86-64 build of 7.3-rc4 as uid 1000 (uverbs0 is 0666
after a one-time "rdma link add"), cross-checked via the CQE-status bit
oracle. Present unchanged in mainline 551c722f4080 (2026-09-29) and rdma
for-next. Compile-tested (KASAN+RDMA_RXE), not runtime-tested. Found through
manual review; per security-bugs.rst this is public and a reproducer can be
shared on request.

 drivers/infiniband/sw/rxe/rxe_mr.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c
b/drivers/infiniband/sw/rxe/rxe_mr.c
index 71d9ea477289..b9aff32fffad 100644
--- a/drivers/infiniband/sw/rxe/rxe_mr.c
+++ b/drivers/infiniband/sw/rxe/rxe_mr.c
@@ -437,6 +437,11 @@ int copy_data(
  goto err2;
  }

+ if (unlikely(dma->cur_sge >= dma->num_sge)) {
+ err = -EINVAL;
+ goto err2;
+ }
+
  if (sge->length && (offset < sge->length)) {
  mr = lookup_mr(pd, access, sge->lkey, RXE_LOOKUP_LOCAL);
  if (!mr) {
--
2.43.0

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

[Greg KH]

On Thu, Oct 01, 2026 at 12:15:52AM +0900, AYS wrote:
> A user QP's receive queue is an mmap'd ring: the user provider writes the
> WQEs and post_recv does not touch them, so every field of struct
> rxe_recv_wqe is attacker controlled. When the responder takes a WQE it
> validates only dma.num_sge (rxe_get_recv_wqe()/get_srq_wqe()); dma.cur_sge,
> dma.sge_offset and dma.resid are copied into qp->resp.srq_wqe unchecked.
> 
> copy_data() then uses cur_sge as an index immediately --
> struct rxe_sge *sge = &dma->sge[dma->cur_sge];
> -- and dereferences it (sge->length) before the in-loop
> "dma->cur_sge >= dma->num_sge" test, which only runs after the first sge++.
> cur_sge is a u32, so this reads far out of bounds of the RXE_MAX_SGE-entry
> dma->sge[] embedded in the kmalloc-2k struct rxe_qp: an information leak (the
> out-of-bounds sge->length is recoverable through the work-completion status)
> and a DoS. The send queue already got this check in commit 126c757e4cd4; the
> receive path did not.
> 
> Reject an out-of-range cur_sge in copy_data() before the first sge
> dereference. This also covers the send retry path and is harmless to the
> kernel ULP path, which always sets cur_sge = 0.
> 
> Fixes: 8700e3e7c485 ("Soft RoCE driver")
> Signed-off-by: Youngsung Ahn <ays511.kr@gmail.com>

Does not match the "From:" line :(

No cc: stable?

No Assisted-by: line?

thanks,

greg k-h

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

[Youngsung Ahn]

A user QP's receive queue is an mmap'd ring: the user provider
writes the WQEs and post_recv does not touch them, so every field of
struct rxe_recv_wqe is attacker controlled. When the responder takes
a WQE it validates only dma.num_sge (rxe_get_recv_wqe() /
get_srq_wqe()); dma.cur_sge, dma.sge_offset and dma.resid are copied
into qp->resp.srq_wqe unchecked.

copy_data() then uses cur_sge as an index immediately --
	struct rxe_sge *sge = &dma->sge[dma->cur_sge];
-- and dereferences it (sge->length) before the in-loop
"dma->cur_sge >= dma->num_sge" test, which only runs after the first
sge++. cur_sge is a u32, so this reads far out of bounds of the
RXE_MAX_SGE-entry dma->sge[] embedded in the kmalloc-2k struct
rxe_qp: an information leak (the out-of-bounds sge->length is
recoverable through the work-completion status) and a DoS. The send
queue already got this check in
commit 126c757e4cd4 ("RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[]");
the receive path did not.

Reject an out-of-range cur_sge in copy_data() before the first sge
dereference. This also covers the send retry path and is harmless to
the kernel ULP path, which always sets cur_sge = 0.

Fixes: 8700e3e7c485 ("Soft RoCE driver")
Signed-off-by: Youngsung Ahn <ays511.kr@gmail.com>
---
Notes (not part of the commit):
Reproduced on a KASAN x86-64 build of 7.3-rc4 as uid 1000 (uverbs0 is 0666
after a one-time "rdma link add"), cross-checked via the CQE-status bit
oracle. Present unchanged in mainline 551c722f4080 (2026-09-29) and rdma
for-next. Compile-tested (KASAN+RDMA_RXE), not runtime-tested. Found through
manual review; per security-bugs.rst this is public and a reproducer can be
shared on request.

 drivers/infiniband/sw/rxe/rxe_mr.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c
index 71d9ea477289..b9aff32fffad 100644
--- a/drivers/infiniband/sw/rxe/rxe_mr.c
+++ b/drivers/infiniband/sw/rxe/rxe_mr.c
@@ -437,6 +437,11 @@ int copy_data(
 		goto err2;
 	}

+	if (unlikely(dma->cur_sge >= dma->num_sge)) {
+		err = -EINVAL;
+		goto err2;
+	}
+
 	if (sge->length && (offset < sge->length)) {
 		mr = lookup_mr(pd, access, sge->lkey, RXE_LOOKUP_LOCAL);
 		if (!mr) {
--
2.43.0

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

[sashiko-bot]

> A user QP's receive queue is an mmap'd ring: the user provider
> writes the WQEs and post_recv does not touch them, so every field of
> struct rxe_recv_wqe is attacker controlled. When the responder takes
> a WQE it validates only dma.num_sge (rxe_get_recv_wqe() /
> get_srq_wqe()); dma.cur_sge, dma.sge_offset and dma.resid are copied
> into qp->resp.srq_wqe unchecked.
> 
> copy_data() then uses cur_sge as an index immediately --
> 	struct rxe_sge *sge = &dma->sge[dma->cur_sge];
> -- and dereferences it (sge->length) before the in-loop
> "dma->cur_sge >= dma->num_sge" test, which only runs after the first
> sge++. cur_sge is a u32, so this reads far out of bounds of the
> RXE_MAX_SGE-entry dma->sge[] embedded in the kmalloc-2k struct
> rxe_qp: an information leak (the out-of-bounds sge->length is
> recoverable through the work-completion status) and a DoS. The send
> queue already got this check in
> commit 126c757e4cd4 ("RDMA/rxe: Validate num_sge/cur_sge before indexing wqe->dma.sge[]");
> the receive path did not.
> 
> Reject an out-of-range cur_sge in copy_data() before the first sge
> dereference. This also covers the send retry path and is harmless to
> the kernel ULP path, which always sets cur_sge = 0.
> 
> Fixes: 8700e3e7c485 ("Soft RoCE driver")
> Signed-off-by: Youngsung Ahn <ays511.kr@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

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

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

[Willy Tarreau]

Hello,

On Wed, Sep 30, 2026 at 11:02:13PM +0900, AYS wrote:
(...)
> diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c
> b/drivers/infiniband/sw/rxe/rxe_mr.c
> index 71d9ea477289..b9aff32fffad 100644
> --- a/drivers/infiniband/sw/rxe/rxe_mr.c
> +++ b/drivers/infiniband/sw/rxe/rxe_mr.c
> @@ -437,6 +437,11 @@ int copy_data(
>   goto err2;
>   }
> 
> + if (unlikely(dma->cur_sge >= dma->num_sge)) {
> + err = -EINVAL;
> + goto err2;
> + }
> +
>   if (sge->length && (offset < sge->length)) {
>   mr = lookup_mr(pd, access, sge->lkey, RXE_LOOKUP_LOCAL);
>   if (!mr) {

All your messages arrive mangled. Please fix your email clients after
consulting Documentation/process/email-clients.rst. Also as a general
rule it's not a good idea to send a flood of messages without verifying
that the setup is OK, because now everyone will delete your whole series
without checking further. You'd rather wait at least a day before
resending to avoid your second series being trashed by accident in the
same batch. Also don't forget to mark them v2.

Willy

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

[Leon Romanovsky]

On Wed, Sep 30, 2026 at 05:34:55PM +0200, Greg KH wrote:
> On Thu, Oct 01, 2026 at 12:15:52AM +0900, AYS wrote:
> > A user QP's receive queue is an mmap'd ring: the user provider writes the
> > WQEs and post_recv does not touch them, so every field of struct
> > rxe_recv_wqe is attacker controlled. When the responder takes a WQE it
> > validates only dma.num_sge (rxe_get_recv_wqe()/get_srq_wqe()); dma.cur_sge,
> > dma.sge_offset and dma.resid are copied into qp->resp.srq_wqe unchecked.
> > 
> > copy_data() then uses cur_sge as an index immediately --
> > struct rxe_sge *sge = &dma->sge[dma->cur_sge];
> > -- and dereferences it (sge->length) before the in-loop
> > "dma->cur_sge >= dma->num_sge" test, which only runs after the first sge++.
> > cur_sge is a u32, so this reads far out of bounds of the RXE_MAX_SGE-entry
> > dma->sge[] embedded in the kmalloc-2k struct rxe_qp: an information leak (the
> > out-of-bounds sge->length is recoverable through the work-completion status)
> > and a DoS. The send queue already got this check in commit 126c757e4cd4; the
> > receive path did not.
> > 
> > Reject an out-of-range cur_sge in copy_data() before the first sge
> > dereference. This also covers the send retry path and is harmless to the
> > kernel ULP path, which always sets cur_sge = 0.
> > 
> > Fixes: 8700e3e7c485 ("Soft RoCE driver")
> > Signed-off-by: Youngsung Ahn <ays511.kr@gmail.com>
> 
> Does not match the "From:" line :(
> 
> No cc: stable?

No need to CC stable@ on RXE patches; I will remove it when applying them anyway.
Nothing urgent here.

Thanks

> 
> No Assisted-by: line?
> 
> thanks,
> 
> greg k-h
> 

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

[Zhu Yanjun]

在 2026/9/30 8:34, Greg KH 写道:
> On Thu, Oct 01, 2026 at 12:15:52AM +0900, AYS wrote:
>> A user QP's receive queue is an mmap'd ring: the user provider writes the
>> WQEs and post_recv does not touch them, so every field of struct
>> rxe_recv_wqe is attacker controlled. When the responder takes a WQE it
>> validates only dma.num_sge (rxe_get_recv_wqe()/get_srq_wqe()); dma.cur_sge,
>> dma.sge_offset and dma.resid are copied into qp->resp.srq_wqe unchecked.
>>
>> copy_data() then uses cur_sge as an index immediately --
>> struct rxe_sge *sge = &dma->sge[dma->cur_sge];
>> -- and dereferences it (sge->length) before the in-loop
>> "dma->cur_sge >= dma->num_sge" test, which only runs after the first sge++.
>> cur_sge is a u32, so this reads far out of bounds of the RXE_MAX_SGE-entry
>> dma->sge[] embedded in the kmalloc-2k struct rxe_qp: an information leak (the
>> out-of-bounds sge->length is recoverable through the work-completion status)
>> and a DoS. The send queue already got this check in commit 126c757e4cd4; the
>> receive path did not.
>>
>> Reject an out-of-range cur_sge in copy_data() before the first sge
>> dereference. This also covers the send retry path and is harmless to the
>> kernel ULP path, which always sets cur_sge = 0.
>>
>> Fixes: 8700e3e7c485 ("Soft RoCE driver")
>> Signed-off-by: Youngsung Ahn <ays511.kr@gmail.com>
> 
> Does not match the "From:" line :(
> 
> No cc: stable?
> 
> No Assisted-by: line?

In v2, this Assisted-by tag has been added.

Yanjun Zhu>
> thanks,
> 
> greg k-h