CVE-2026-72221

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

sunrpc: wait for in-flight TLS handshake callback when cancel loses race

When wait_for_completion_interruptible_timeout() in

svc_tcp_handshake() returns 0 (timeout) or -ERESTARTSYS (signal) and

tls_handshake_cancel() then returns false, handshake_complete() has

won the cancellation race: it has set HANDSHAKE_F_REQ_COMPLETED and

is about to invoke svc_tcp_handshake_done(), but the callback's

side effects on xpt_flags and on svsk->sk_handshake_done have not

yet committed.

The current code reads xpt_flags immediately to decide whether the

session succeeded. Two races result.

If the callback has executed set_bit(XPT_TLS_SESSION) but not yet

clear_bit(XPT_HANDSHAKE), svc_tcp_handshake() sees a session,

enqueues the transport, and returns. svc_xprt_received() then

clears XPT_BUSY, a worker thread picks the transport up, the

dispatcher in svc_handle_xprt() observes XPT_HANDSHAKE still set,

and xpo_handshake is invoked a second time. That svc_tcp_handshake()

calls init_completion(&svsk->sk_handshake_done) while the original

callback concurrently calls complete_all() on it, corrupting the

embedded swait_queue.

If the callback has set HANDSHAKE_F_REQ_COMPLETED but not yet

entered svc_tcp_handshake_done(), svc_tcp_handshake() reads

XPT_TLS_SESSION as clear and tears the connection down even though

the handshake is about to succeed.

Wait for the callback to commit before inspecting xpt_flags. The

completion is guaranteed to fire because handshake_complete()

invokes svc_tcp_handshake_done() unconditionally once it has set

HANDSHAKE_F_REQ_COMPLETED.