[BUG] RDMA/rxe: user QP can submit kernel-only REG_MR opcode

[sungbyeongchan]

Hello,

I found a raw kernel-pointer dereference reachable from an RXE user
send queue.

RXE user QPs expose their send queues through mmap.  A userspace client
can publish opcode IB_WR_REG_MR even though that opcode and its struct
ib_mr pointer are kernel-only.  The RXE opcode table enables the local
operation on RC QPs, and rxe_do_local_ops() passes the shared WQE to
rxe_reg_fast_mr().  The latter interprets reserved userspace union bytes
as a struct ib_mr pointer without a handle lookup or acquired reference.

I reproduced this twice on commit
ff47652a4b66c067c765a7ad464d930b5a9367cc.  An unprivileged uid/gid
65534 client published IB_WR_REG_MR with zero pointer bytes in its mapped
SQ.  Both runs produced a fatal fault in rxe_reg_fast_mr() and a kernel
panic.  A control using IB_WR_LOCAL_INV traversed the same local-operation
dispatcher without a sanitizer report or oops.

The demonstrated impact is a deterministic unprivileged denial of
service through a raw-pointer type confusion.  Although the source has
conditional MR field writes after several checks, I did not reach those
writes and do not claim arbitrary write, information disclosure, code
execution, or privilege escalation.

I tested rejecting IB_WR_REG_MR on user QPs before rxe_reg_fast_mr() is
called.  Kernel QPs retain the existing path.  The malicious case and
normal control were both clean after the change, 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 submission of kernel-only REG_MR
through an RXE user-mapped SQ.

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