In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: wait for in-flight client TLS handshake callback
xs_tls_handshake_sync() gives xs_tls_handshake_done() a reference to the
lower transport before submitting the handshake request. On timeout or
signal, the synchronous waiter drops that reference after calling
tls_handshake_cancel().
handshake_req_cancel() returns false when handshake_complete() has
already marked the request complete. In that case the completion callback
can still be running, so dropping the callback-owned reference in the
waiter can free the lower transport before xs_tls_handshake_done() stores
xprt_err or drops its own reference.
If cancellation loses to completion, wait until xs_tls_handshake_done()
signals handshake_done and let the callback release its reference. This
mirrors the server-side handshake lifetime handling and keeps the timeout
or signal return value unchanged.
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 bug is in the SUNRPC TCP-with-TLS client handshake (xs_tls_handshake_sync), reached when a remote NFS/RPC peer completes RPC-with-TLS; a malicious server or on-path attacker with xprtsec=tls (anonymous TLS) drives handshake_complete() over the network against the client's 10s wait.
AC:L - The attacker times TLS completion against the fixed XS_TLS_HANDSHAKE_TO window and can force repeated reconnects so tls_handshake_cancel() losing to handshake_complete() is reliably hittable, with no memory-layout guess or other condition outside attacker control.
PR:N - No privileges on the victim host are required; a remote TLS peer only needs the client to initiate or re-establish an RPC-with-TLS connection, and the handshake runs after AUTH_TLS STARTTLS but before NFS credentials are verified.
UI:N - No victim action is needed at attack time once an NFS xprtsec=tls/mtls mount exists, because idle disconnect or server-induced reconnect automatically re-enters xs_tcp_tls_setup_socket() and the handshake wait.
S:U - The use-after-free corrupts kernel heap state in the SUNRPC client on the same host; impact stays within that kernel's security authority and does not cross a VM, IOMMU, or sandbox boundary.
C:H - When cancel loses, the waiter still xprt_put()s the callback-owned rpc_xprt reference, so sock_xprt can be freed while xs_tls_handshake_done() writes xprt_err and the connect worker still uses lower_xprt, a heap UAF enabling arbitrary disclosure.
I:H - Use-after-free of rpc_xprt/sock_xprt (ops pointers, wait queues, socket state) allows heap reuse for arbitrary writes and control-flow hijacking, not merely a crash.
A:H - The extra put can destroy the transport while the handshake waiter and connect worker still touch it, producing a kernel oops/panic or a hang in xprt_destroy waiting on XPRT_LOCKED, denying NFS/RPC service.
| 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 bug is in the SUNRPC TCP-with-TLS client handshake (xs_tls_handshake_sync), reached when a remote NFS/RPC peer completes RPC-with-TLS; a malicious server or on-path attacker with xprtsec=tls (anonymous TLS) drives handshake_complete() over the network against the client's 10s wait.
AC:L - The attacker times TLS completion against the fixed XS_TLS_HANDSHAKE_TO window and can force repeated reconnects so tls_handshake_cancel() losing to handshake_complete() is reliably hittable, with no memory-layout guess or other condition outside attacker control.
PR:N - No privileges on the victim host are required; a remote TLS peer only needs the client to initiate or re-establish an RPC-with-TLS connection, and the handshake runs after AUTH_TLS STARTTLS but before NFS credentials are verified.
UI:N - No victim action is needed at attack time once an NFS xprtsec=tls/mtls mount exists, because idle disconnect or server-induced reconnect automatically re-enters xs_tcp_tls_setup_socket() and the handshake wait.
S:U - The use-after-free corrupts kernel heap state in the SUNRPC client on the same host; impact stays within that kernel's security authority and does not cross a VM, IOMMU, or sandbox boundary.
C:H - When cancel loses, the waiter still xprt_put()s the callback-owned rpc_xprt reference, so sock_xprt can be freed while xs_tls_handshake_done() writes xprt_err and the connect worker still uses lower_xprt, a heap UAF enabling arbitrary disclosure.
I:H - Use-after-free of rpc_xprt/sock_xprt (ops pointers, wait queues, socket state) allows heap reuse for arbitrary writes and control-flow hijacking, not merely a crash.
A:H - The extra put can destroy the transport while the handshake waiter and connect worker still touch it, producing a kernel oops/panic or a hang in xprt_destroy waiting on XPRT_LOCKED, denying NFS/RPC service.
CVSS 3.1