Linux kernel (net/rds): If RDS/IB queue-pair setup fails after the send ring is allocated but before the receive ring

Impact

If RDS/IB queue-pair setup fails after the send ring is allocated but before the receive ring is, the unwind frees the send ring without clearing the pointer. The teardown logic uses NULL to decide what it still owns, so a later shutdown pass frees the same ring again - a double free / use-after-free of RDMA send state reachable by whoever can make connection setup fail partway.

Who can reach it

Driven from the fabric: RDS/IB connection setup runs from the RDMA CM event handler when a peer connects, and the failure window is a partial setup (resource exhaustion, device limits, a peer that aborts mid-setup), followed by the normal shutdown path. A tenant can also drive repeated RDS connection attempts locally - socket(AF_RDS, ...) is unprivileged and autoloads rds/rds_rdma via the net-pf-21 alias. Requires the RDS RDMA transport in use over an IB/RoCE device.

What to do

Boot a kernel carrying the fix commits (clears i_sends after vfree in the setup unwind). Interim: blacklist rds and rds_rdma, or deny socket family 21 to tenants; RDS over IB is rarely a deliberate dependency on an AI cluster.

References