[BUG] RDMA/rxe: unchecked receive WQE cursor causes OOB access

[BUG] RDMA/rxe: unchecked receive WQE cursor causes OOB access

[sungbyeongchan]

Hello,

I found a receive-WQE validation gap in RXE after the WQE is copied from
a userspace-mapped receive queue.

rxe_get_recv_wqe() bounds dma.num_sge and uses it to size the private
snapshot, but it does not validate dma.cur_sge.  For a nonempty receive,
copy_data() later uses cur_sge to select SGE metadata without proving
that the cursor is below num_sge.  The equivalent omission also exists
in get_srq_wqe().

I reproduced this twice on commit
ff47652a4b66c067c765a7ad464d930b5a9367cc.  An unprivileged uid 65534
RXE queue owner published num_sge=1, resid=8, and
cur_sge=UINT32_MAX.  An ordinary inline SEND from a connected peer then
caused the same OOB metadata access and fatal kernel fault in copy_data()
in both runs.  Changing only cur_sge to zero delivered the expected
eight-byte payload without a sanitizer report or oops.

The demonstrated impact is an unprivileged kernel denial of service.
I did not demonstrate a valid bogus lkey/address, controlled kernel
write, information disclosure, code execution, or privilege escalation.

I tested validating num_sge and cur_sge on the immutable receive-WQE
snapshot in both the per-QP and SRQ paths.  The malformed WQE was
rejected and the normal receive still completed.  Fixed A/B validation
passed.

This is related to the earlier RXE receive-WQE TOCTOU work associated
with CVE-2026-74377, but appears to be a residual invariant: copying the
WQE prevents subsequent mutation while leaving the copied cur_sge value
unchecked.  I found no exact public patch for this residual check in a
best-effort search through 2026-10-06.

This report was prepared with AI assistance and is being treated as
public under Documentation/process/security-bugs.rst.  A tested source
reproducer, logs, configuration, and proposed patch are available to the
maintainers on request; the reproducer is intentionally not attached to
this public report.

Assisted-by: LLM

Regards,
sungbyeongchan

Re: [BUG] RDMA/rxe: unchecked receive WQE cursor causes OOB access

[Willy Tarreau]

Hello,

On Tue, Oct 06, 2026 at 06:12:38PM +0900, sungbyeongchan wrote:
> This report was prepared with AI assistance and is being treated as
> public under Documentation/process/security-bugs.rst.  A tested source
> reproducer, logs, configuration, and proposed patch are available to the
> maintainers on request; the reproducer is intentionally not attached to
> this public report.

Please do *always* post a patch. Maintainers receive lots of messages
like this one every single day, there's no point sending a message
saying "you might be interested in a patch I have" without sending
the patch, it wastes time and effort doing round trips. Just send it.
Same for the reproducers, if they're not too big, just send them to
the maintainers (not the mailing lists) so they have everything to
start working on when they open their mailbox.

Thanks,
Willy

Re: [BUG] RDMA/rxe: unchecked receive WQE cursor causes OOB access

[Zhu Yanjun]

在 2026/10/6 19:51, Willy Tarreau 写道:
> Hello,
> 
> On Tue, Oct 06, 2026 at 06:12:38PM +0900, sungbyeongchan wrote:
>> This report was prepared with AI assistance and is being treated as
>> public under Documentation/process/security-bugs.rst.  A tested source
>> reproducer, logs, configuration, and proposed patch are available to the
>> maintainers on request; the reproducer is intentionally not attached to
>> this public report.
> 
> Please do *always* post a patch. Maintainers receive lots of messages
> like this one every single day, there's no point sending a message
> saying "you might be interested in a patch I have" without sending
> the patch, it wastes time and effort doing round trips. Just send it.
> Same for the reproducers, if they're not too big, just send them to
> the maintainers (not the mailing lists) so they have everything to
> start working on when they open their mailbox.
> 

Thanks a lot. Willy. With AI assistance, too many problems have been found.

Yanjun Zhu

> Thanks,
> Willy