Linux kernel - RDMA/rtrs server (RDMA Transport, used by RNBD block storage), drivers/infiniband/ulp/rtrs/rtrs-srv.c

Impact

When the RTRS server answers a READ it builds the RDMA WRITE source scatter/gather entry with a length taken straight off the wire descriptor, which the remote peer filled itself, and the source lkey used is the PD-wide local_dma_lkey rather than a key bound to that chunk's mapping - so the verbs layer never constrains the transfer to the chunk size. A peer advertising a length larger than max_chunk_size makes the NIC read past the chunk's mapped region and ship the result back over the fabric. With no IOMMU or in passthrough mode - a common configuration on high-performance storage nodes chasing latency - that returns adjacent host memory to the attacker. This is exactly the disaggregated-storage tenant-isolation break operators worry about: one client reads memory belonging to the server and, by extension, to other clients.

Who can reach it

The attacker is an RTRS client connected to the server - the normal trust position for a storage tenant. They set desc[0].len in the read descriptor larger than the negotiated chunk size; before the fix only a zero length was rejected. With a translating IOMMU the over-range access faults and drops the connection (denial of service instead of disclosure), so IOMMU configuration decides whether this reads memory or just breaks the session.

What to do

Host reboot / kernel upgrade on RTRS/RNBD server nodes. Interim config changes that materially reduce impact: enable the IOMMU in translating (not passthrough) mode on storage servers, which converts disclosure into a connection abort - this is a kernel command-line change requiring a reboot anyway, so fold it into the same maintenance window and expect a small latency cost. Restrict RTRS server ports to authenticated client subnets. If RNBD/RTRS is not in use, ensure the modules are not loaded.

References