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. xs_connect()

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, cl_prog,

clvers, clcred, cl_stats) to construct the args for the

inner handshake rpc_clnt.

The xprt does not reference the rpcclnt; the rpcclnt

references the xprt. xs_destroy() does cancel the

connect_worker, but it runs only when the xprt's refcount

drops to zero, which cannot happen until the rpc_clnt

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 rpc_clnt

is freed before the queued connect_worker fires.

xstcptlssetupsocket() then dereferences the freed clnt,

producing the refcount_t 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 rpcrelease_client().

The xprtlockconnect() / xprtunlockconnect() pairing

already serialises xsconnect() with xstcptlssetup_socket(),

so the take and release are balanced one-for-one.

The non-TLS connect worker (xstcpsetup_socket) never reads

sock_xprt::clnt, so leave that path alone and avoid the

clnt-holds-xprt-holds-clnt cycle that would otherwise prevent

xprt destruction.