[BUG] RDMA/rxe: MW rkey authorizes accesses outside the bound range

[sungbyeongchan]

Hello,

I found a memory-window range authorization bug in the RXE responder.

A peer with a valid type-2 MW rkey can issue RDMA READ or WRITE outside
the interval authorized by the MW bind, provided the request remains
inside the wider backing MR.  rxe_lookup_mw() validates the key, PD, QP,
access rights, state, and nonzero length, but check_rkey() checks the
request address only against the backing MR.  It never checks the full
request extent against mw->addr and mw->length.

I reproduced this twice on commit
ff47652a4b66c067c765a7ad464d930b5a9367cc.  A 64-byte type-2 MW at
offset 1024 in a 4096-byte MR allowed a valid connected peer to read an
eight-byte sentinel at offset 2048 and replace it with peer-selected
bytes.  In-window READ and WRITE succeeded, while a request crossing the
backing-MR end was rejected.

The demonstrated impact is disclosure and modification of registered
userspace memory outside the delegated MW.  I did not demonstrate kernel
memory access, a kernel crash, code execution, or privilege escalation.

The affected path is:

  rxe_responder()
    -> check_rkey()
      -> rxe_lookup_mw()
      -> mr_check_range() against only the backing MR

I tested an overflow-safe MW interval check immediately after MW lookup.
With that change, outside-window READ and WRITE return a remote-access
error, while valid in-window operations continue to work.  Fixed A/B
testing passed with the same kernel configuration.

I performed a best-effort public duplicate search through 2026-10-06.
The public RXE MW/MR lifetime-race series addresses reference and object
lifetime races, not this missing MW range check; I found no exact public
report of this range bypass.

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