AZL-96543

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

xprtrdma: Fix ep kref imbalance on ADDR_CHANGE

rpcrdmacmeventhandler() falls through to the disconnected: label on RDMACMEVENTADDRCHANGE and calls rpcrdmaepput() with no matching get when the event arrives before RDMACMEVENTESTABLISHED. The kref then underflows during connect teardown and rpcrdmaxprtdisconnect() operates on a freed ep.

Reference counts across a normal connection lifecycle:

rpcrdma_ep_create()             kref_init     ->1
rpcrdma_xprt_connect()          ep_get        ->2  (before post_recvs)
RDMA_CM_EVENT_ESTABLISHED       ep_get        ->3
RDMA_CM_EVENT_DISCONNECTED      ep_put        ->2
rpcrdma_xprt_drain()            ep_put        ->1
rpcrdma_xprt_disconnect() tail  ep_put        ->0  (ep_destroy)

The connect-time get in rpcrdmaxprtconnect(), taken just before rpcrdmapostrecvs() "while there are outstanding Receives," is balanced by rpcrdmaxprtdrain. ADDRCHANGE before ESTABLISHED has no get to consume, so its put drops the count to 1 and the drain put then frees the ep while rpcrdmaxprt_disconnect() still holds a pointer to it.

Fix by dispatching on the prior reconnectstatus via xchg(): for prev == 0 (pre-ESTABLISHED) wake the connect waiter and return with no put; for prev == 1 call rpcrdmaforcedisconnect() and return. The case-1 arm relies on the subsequent RDMACMEVENTDISCONNECTED event -- reliably delivered when rdmadisconnect() is called on a still-connected cmid -- to balance the ESTABLISHED get; rpcrdmaxprt_drain() continues to balance only that connect-time get. Any other prior value means teardown is already in flight.