CVE-2026-72317

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

SUNRPC: pin upper rpcclnt across the TLS connectworker

The TLS connect path has a use-after-free: nothing pins the upper rpcclnt across the delayed connectworker. xsconnect() stores task->tkclient in sockxprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xstcptlssetupsocket(), which reads several fields out of the saved pointer (cltimeout, clprogram, clprog, clvers, clcred, clstats) to construct the args for the inner handshake rpcclnt.

The xprt does not reference the rpcclnt; the rpcclnt references the xprt. xsdestroy() does cancel the connectworker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpcclnt releases its clxprt reference in rpcfreeclientwork(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpcshutdownclient(), and the upper rpcclnt is freed before the queued connectworker fires. xstcptlssetupsocket() then dereferences the freed clnt, producing the refcountt underflow Michael Nemanov reported.

Take a reference on the upper rpcclnt in xsconnect() for TLS transports via a new rpcholdclient() helper, and drop it in the connectworker's exit path with rpcreleaseclient(). The xprtlockconnect() / xprtunlockconnect() pairing already serialises xsconnect() with xstcptlssetupsocket(), so the take and release are balanced one-for-one.

The non-TLS connect worker (xstcpsetupsocket) never reads sockxprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.