CVE-2026-63979

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

net/handshake: hand off the pinned file reference to accept_doit

handshakereqnext() removes the request from the per-net

pending list and drops hnlock before handshakenlacceptdoit()

reads req->hrsk->sksocket and dereferences sock->file (once in

FDPREPARE() and again in getfile()).  In that window a

consumer running tlshandshakecancel() followed by sockfd_put()

(svcsockfree) or _fputsync() (xsresettransport) releases

sock->file.  sockrelease() then runs sockorphan(), zeroing

sk_socket, and frees the struct socket.  The accept-side code

either reads NULL through sk_socket or chases freed memory.

The submit-side sockhold() does not prevent this.  skrefcnt

protects struct sock, but struct socket and sock->file are

independently refcounted via the file descriptor the consumer

owns.  Pinning sk leaves sock and sock->file unprotected.

Retarget the accept-side dereferences at req->hr_file, which was

pinned at submit time, instead of req->hrsk->sksocket->file.

Pinning on its own is not sufficient: a consumer that cancels

between handshakereqnext() returning and accept_doit reaching

FDPREPARE() takes the !removepending() branch in

handshakereqcancel() and drops hr_file before the accept side

takes its own reference.  Hand off an additional file reference

inside handshakereqnext(), under hn_lock, so the accept side

operates on a reference that no concurrent handshakereqcancel()

can revoke.  FD_PREPARE() consumes that handed-off reference,

either by transferring it to the new fd in fd_publish() or by

dropping it in the cleanup destructor on error; the explicit

getfile() that previously balanced FDPREPARE() is therefore

redundant and goes away.

Update handshakereqcanceltest2 and test3 to simulate the

FD_PREPARE() consumption with an fput() so the kunit file-count

assertions stay balanced.