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 waitforcompletioninterruptibletimeout() in

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

tlshandshakecancel() then returns false, handshake_complete() has

won the cancellation race: it has set HANDSHAKEFREQ_COMPLETED and

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

side effects on xptflags and on svsk->skhandshake_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 setbit(XPTTLS_SESSION) but not yet

clearbit(XPTHANDSHAKE), svctcphandshake() sees a session,

enqueues the transport, and returns. svcxprtreceived() then

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

dispatcher in svchandlexprt() observes XPT_HANDSHAKE still set,

and xpohandshake is invoked a second time. That svctcp_handshake()

calls initcompletion(&svsk->skhandshake_done) while the original

callback concurrently calls complete_all() on it, corrupting the

embedded swait_queue.

If the callback has set HANDSHAKEFREQ_COMPLETED but not yet

entered svctcphandshakedone(), svctcp_handshake() reads

XPTTLSSESSION 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 svctcphandshake_done() unconditionally once it has set

HANDSHAKEFREQ_COMPLETED.