[BUG] RDMA/rxe: mapped SQ opcode indexes past opcode table

[sungbyeongchan]

Hello,

I found an unchecked opcode-table index in the RXE requester path.

An RXE user QP exposes its send queue through mmap.  req_next_wqe()
passes the userspace-controlled WQE opcode to wr_opcode_mask(), which
indexes rxe_wr_opcode_info[] before checking whether the opcode is in
range or implemented.

I reproduced this twice on commit
ff47652a4b66c067c765a7ad464d930b5a9367cc.  An unprivileged uid/gid
65534 client published UINT32_MAX as the opcode and woke the production
requester.  Both KASAN boots reported the same four-byte global
out-of-bounds read.  Changing only the opcode to a normal SEND reached
the same requester without KASAN or an oops.

The demonstrated impact is a kernel memory-safety violation detected by
KASAN.  I did not demonstrate disclosure of the read value, a write
primitive, a reliable crash on a non-instrumented kernel, code execution,
or privilege escalation.

I tested an unsigned upper-bound check before the opcode table lookup.
It rejects negative signed values and values beyond the implemented
table while preserving the normal invalid-WQE path.  The malicious case
and normal SEND control were clean on the fixed kernel, and fixed A/B
testing passed.

I performed a best-effort public duplicate search through 2026-10-06
and found no exact public report for this RXE opcode-table bounds issue.

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