Linux kernel (net/rds): RDS always programs the masked variants of the RDMA atomic opcodes, but the send-completion

Impact

RDS always programs the masked variants of the RDMA atomic opcodes, but the send-completion path only recognises the unmasked ones, so every atomic operation completes with a NULL message pointer that is then dereferenced. A tenant sending one atomic control message over an RDS/IB connection panics the node from softirq - the commit states plainly that an unprivileged AF_RDS sendmsg() triggers it with no extra setup on mlx4/mlx5.

Who can reach it

Local and unprivileged, single syscall: socket(AF_RDS, SOCK_SEQPACKET, 0) - which autoloads the rds and rds_rdma modules through the net-pf-21 alias with no capability check - then sendmsg() with an RDS atomic cmsg over an active RDS/IB connection. Requires an RDMA device the tenant's traffic can use, which is the normal case on a GPU node, and native masked-atomic support (mlx4/mlx5). The fault is in the completion tasklet, so it is a fatal exception in interrupt context: the whole node goes down.

What to do

Boot a kernel carrying the fix commits (handles the masked atomic opcodes in the completion unmap path). Interim: blacklist the rds, rds_rdma and rds_tcp modules (install rds /bin/false) or deny socket family 21 in tenant seccomp profiles - RDS is almost never intentionally used on a GPU cluster and is a good candidate for blanket removal.

References