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

Impact

TENANT ISOLATION: atomic_write_reply() dereferences 8 bytes at the payload address unconditionally, while the rkey check accepted an ATOMIC_WRITE with a RETH length of zero. A remote initiator sending a zero-length ATOMIC_WRITE makes the responder read 8 bytes past the logical end of the packet into the socket buffer's tailroom and then write those bytes into the attacker's own memory region. That is a clean remote read primitive: four bytes of uninitialised kernel memory disclosed to the attacker per probe, repeatable at will, ideal for defeating KASLR or harvesting kernel pointers before a heavier exploit. The IB specification defines ATOMIC_WRITE as exactly 8 bytes, so anything else was always protocol-invalid.

Who can reach it

Remote initiator on an rxe connection sets the RETH length to 0 on an ATOMIC_WRITE and reads back the responder's reply, which now contains kernel tailroom bytes. Repeat to accumulate a memory-disclosure oracle. No local privilege and no authentication beyond reaching the Soft-RoCE endpoint.

What to do

Host reboot / kernel upgrade. Same family control as the other rxe findings: blacklist and unload rdma_rxe where Soft-RoCE is not intentionally deployed, which is a config change with no downtime and removes this along with the rest. Where rxe is in use, upgrade the kernel and reboot on rolling drain, and firewall UDP/4791 to known peers in the meantime.

References