Linux kernel - RDMA/rxe (Soft-RoCE) responder, drivers/infiniband/sw/rxe/rxe_resp.c: TENANT ISOLATION: The shared

Impact

TENANT ISOLATION: The shared receive queue buffer is mapped into userspace, and get_srq_wqe() validates the num_sge field from that buffer against max_sge but then re-reads the same field to size the memcpy. A local process racing a second thread flips num_sge between the check and the copy and overflows the kernel heap. On a multi-tenant node this is a container-to-kernel escalation reachable by any tenant given an RDMA device - which, for RDMA to be useful at all, is every tenant. Full loss of confidentiality, integrity and availability on the host, meaning escape from the container onto the GPU node and everything else scheduled on it.

Who can reach it

Local, low privilege. The attacker maps the SRQ, posts a work queue entry, and has a concurrent thread rewrite num_sge in the shared mapping in the window between validation and use. Classic time-of-check-to-time-of-use on a userspace-writable structure the kernel reads twice. Requires the rdma_rxe module to be loaded and an rxe device present.

What to do

Host reboot / kernel upgrade. Strong interim mitigation: rxe (Soft-RoCE) is a software RoCE emulation used for development and for nodes without a real RNIC - on a GPU cluster with ConnectX or BlueField hardware it is almost never needed. Unload and blacklist rdma_rxe (config change, no downtime) and this and the other rxe findings in this database all disappear at once. Audit which nodes have it loaded; it is frequently pulled in by test tooling and left behind.

References