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.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - The flaw is in the SUNRPC TCP-with-TLS client connect_worker processing a remote NFS server's TLS handshake; a malicious or misconfigured server can induce fatal handshake failure over the network before the delayed worker runs, matching network-reachable kTLS/RPC-with-TLS client paths.
AC:L - An attacker operating a reachable NFS endpoint can reliably cause fatal TLS handshake failure (e.g., reject mTLS client certificates or send TLS alerts) and influence reconnect timing/backoff so client teardown frees rpc_clnt before the queued connect_worker executes.
PR:N - Exploitation requires no privileges on the victim host; a remote peer only needs the client kernel to initiate or re-establish an NFS RPC-with-TLS connection, and TLS handshake processing occurs before NFS authentication completes.
UI:N - No further victim action is needed once an NFS xprtsec=tls/mtls mount exists because automatic reconnect after server-induced disconnect or handshake failure can trigger the race without additional user interaction.
S:U - Impact is confined to kernel memory corruption and privilege boundaries within the same host; this is standard local kernel compromise rather than crossing VM, container, or IOMMU security scopes.
C:H - This is a kernel heap use-after-free where xs_tcp_tls_setup_socket reads multiple fields from a freed rpc_clnt (including cl_cred and cl_program), enabling information disclosure and further exploitation beyond a simple crash.
I:H - Use-after-free of rpc_clnt permits corrupting allocator metadata and adjacent kernel objects; freed-object reuse can yield arbitrary write or control-flow hijack primitives, not merely authenticated data alteration.
A:H - Accessing the freed rpc_clnt produces a refcount_t underflow and kernel oops/panic; even unsuccessful exploitation typically crashes or hangs the system, and repeated reconnect attempts can deny availability.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - The flaw is in the SUNRPC TCP-with-TLS client connect_worker processing a remote NFS server's TLS handshake; a malicious or misconfigured server can induce fatal handshake failure over the network before the delayed worker runs, matching network-reachable kTLS/RPC-with-TLS client paths.
AC:L - An attacker operating a reachable NFS endpoint can reliably cause fatal TLS handshake failure (e.g., reject mTLS client certificates or send TLS alerts) and influence reconnect timing/backoff so client teardown frees rpc_clnt before the queued connect_worker executes.
PR:N - Exploitation requires no privileges on the victim host; a remote peer only needs the client kernel to initiate or re-establish an NFS RPC-with-TLS connection, and TLS handshake processing occurs before NFS authentication completes.
UI:N - No further victim action is needed once an NFS xprtsec=tls/mtls mount exists because automatic reconnect after server-induced disconnect or handshake failure can trigger the race without additional user interaction.
S:U - Impact is confined to kernel memory corruption and privilege boundaries within the same host; this is standard local kernel compromise rather than crossing VM, container, or IOMMU security scopes.
C:H - This is a kernel heap use-after-free where xs_tcp_tls_setup_socket reads multiple fields from a freed rpc_clnt (including cl_cred and cl_program), enabling information disclosure and further exploitation beyond a simple crash.
I:H - Use-after-free of rpc_clnt permits corrupting allocator metadata and adjacent kernel objects; freed-object reuse can yield arbitrary write or control-flow hijack primitives, not merely authenticated data alteration.
A:H - Accessing the freed rpc_clnt produces a refcount_t underflow and kernel oops/panic; even unsuccessful exploitation typically crashes or hangs the system, and repeated reconnect attempts can deny availability.
CVSS 3.1