CVE-2026-31425

In the Linux kernel, the following vulnerability has been resolved:

rds: ib: reject FRMR registration before IB connection is established

rdsibgetmr() extracts the rdsibconnection from conn->ctransportdata and passes it to rdsibregfrmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rdsibconnalloc() with icmid = NULL because the connection worker has not yet called rdsibconnpathconnect() to create the rdmacmid. When sendmsg() with RDSCMSGRDMAMAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rdsibpostregfrmr() to dereference ic->icmid->qp and crash the kernel.

The existing guard in rdsibreg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists.

KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rdsibpostregfrmr+0x50e/0x920 Call Trace: rdsibpostregfrmr (net/rds/ibfrmr.c:167) rdsibmapfrmr (net/rds/ibfrmr.c:252) rdsibregfrmr (net/rds/ibfrmr.c:430) rdsibgetmr (net/rds/ib_rdma.c:615) __rdsrdmamap (net/rds/rdma.c:295) rdscmsgrdmamap (net/rds/rdma.c:860) rdssendmsg (net/rds/send.c:1363) ___syssendmsg dosyscall64

Add a check in rdsibgetmr() that verifies ic, icmid, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rdsibpostinv(). Return -ENODEV when the connection is not ready, which the existing error handling in rdscmsgsend() converts to -EAGAIN for userspace retry and triggers rdsconnconnectifdown() to start the connection worker.