CVE-2026-31425: rds: ib: reject FRMR registration before IB connection is established

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 rdsibregfrmr() 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/ibrdma.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.