CVE-2026-72317

Published: Ago 15, 2026 Last Modified: Ago 15, 2026

ExploitDB:

Other exploit source:

Google Dorks:

Description

AI Translation Available

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

SUNRPC: pin upper rpc_clnt across the TLS connect_worker

The TLS connect path has a use-after-free: nothing pins the
upper rpc_clnt across the delayed connect_worker. xs_connect()
stores task->tk_client in sock_xprt::clnt as a raw pointer
and queues the worker; for TLS-secured transports that worker
is xs_tcp_tls_setup_socket(), which reads several fields out
of the saved pointer (cl_timeout, cl_program, cl_prog,
cl_vers, cl_cred, cl_stats) to construct the args for the
inner handshake rpc_clnt.

The xprt does not reference the rpc_clnt; the rpc_clnt
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 cl_xprt reference in rpc_free_client_work().
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 rpc_shutdown_client(), and the upper rpc_clnt
is freed before the queued connect_worker fires.
xs_tcp_tls_setup_socket() then dereferences the freed clnt,
producing the refcount_t underflow Michael Nemanov reported.

Take a reference on the upper rpc_clnt in xs_connect() for
TLS transports via a new rpc_hold_client() helper, and drop
it in the connect_worker's exit path with rpc_release_client().
The xprt_lock_connect() / xprt_unlock_connect() pairing
already serialises xs_connect() with xs_tcp_tls_setup_socket(),
so the take and release are balanced one-for-one.

The non-TLS connect worker (xs_tcp_setup_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.

AI Generated Translation

Nel kernel Linux, è stata risolta la seguente vulnerabilità:

SUNRPC: mantenere il puntatore upper rpc_clnt durante il connect_worker TLS

Il percorso di connessione TLS presenta un use-after-free: nulla mantiene il puntatore upper rpc_clnt durante il connect_worker ritardato. xs_connect() memorizza task->tk_client in sock_xprt::clnt come un puntatore raw e mette in coda il worker; per i trasporti protetti da TLS, quel worker è xs_tcp_tls_setup_socket(), che legge diversi campi dal puntatore salvato (cl_timeout, cl_program, cl_prog, cl_vers, cl_cred, cl_stats) per costruire gli argomenti per il handshake interno rpc_clnt.

L'xprt non fa riferimento a rpc_clnt; è rpc_clnt a fare riferimento all'xprt. xs_destroy() annulla il connect_worker, ma ciò avviene solo quando il refcount dell'xprt scende a zero, cosa che non può succedere finché rpc_clnt non rilascia il suo riferimento cl_xprt in rpc_free_client_work(). Quando un handshake TLS fallisce in modo fatale (ad esempio, un mount mTLS con un certificato client che non corrisponde al server), il task di connessione viene svegliato con -EACCES ed esce, il chiamante del mount invoca rpc_shutdown_client(), e l'upper rpc_clnt viene liberato prima che il connect_worker in coda venga eseguito. A quel punto, xs_tcp_tls_setup_socket() dereferenzia il clnt già liberato, causando l'underflow del refcount_t segnalato da Michael Nemanov.

Per risolvere il problema, si prende un riferimento sull'upper rpc_clnt in xs_connect() tramite un nuovo helper rpc_hold_client(), e si rilascia in fase di uscita del connect_worker con rpc_release_client(). La coppia di funzioni xprt_lock_connect() / xprt_unlock_connect() già serializza xs_connect() con xs_tcp_tls_setup_socket(), quindi le operazioni di take e release sono bilanciate una a una.

Il worker di connessione non-TLS (xs_tcp_setup_socket) non legge sock_xprt::clnt, quindi si lascia invariato quel percorso e si evita il ciclo clnt-holds-xprt-holds-clnt che altrimenti impedirebbe la distruzione dell'xprt.