CVE-2026-72469: xprtrdma: Fix ep kref imbalance on ADDR_CHANGE

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

xprtrdma: Fix ep kref imbalance on ADDRCHANGE

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:

rpcrdmaepcreate() krefinit ->1 rpcrdmaxprtconnect() epget ->2 (before postrecvs) RDMACMEVENTESTABLISHED epget ->3 RDMACMEVENTDISCONNECTED epput ->2 rpcrdmaxprtdrain() epput ->1 rpcrdmaxprtdisconnect() tail epput ->0 (epdestroy)

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 rpcrdmaxprtdisconnect() 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; rpcrdmaxprtdrain() continues to balance only that connect-time get. Any other prior value means teardown is already in flight.