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, handshakecomplete() has won the cancellation race: it has set HANDSHAKEFREQCOMPLETED and is about to invoke svctcphandshakedone(), but the callback's side effects on xptflags and on svsk->skhandshakedone 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(XPTTLSSESSION) but not yet clearbit(XPTHANDSHAKE), svctcphandshake() sees a session, enqueues the transport, and returns. svcxprtreceived() then clears XPTBUSY, a worker thread picks the transport up, the dispatcher in svchandlexprt() observes XPTHANDSHAKE still set, and xpohandshake is invoked a second time. That svctcphandshake() calls initcompletion(&svsk->skhandshakedone) while the original callback concurrently calls completeall() on it, corrupting the embedded swait_queue.

If the callback has set HANDSHAKEFREQCOMPLETED but not yet entered svctcphandshakedone(), svctcphandshake() 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 xptflags. The completion is guaranteed to fire because handshakecomplete() invokes svctcphandshakedone() unconditionally once it has set HANDSHAKEFREQCOMPLETED.