DEBIAN-CVE-2026-63979

In the Linux kernel, the following vulnerability has been resolved:  net/handshake: hand off the pinned file reference to acceptdoit  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 sockfdput() (svcsockfree) or _fputsync() (xsresettransport) releases sock->file.  sockrelease() then runs sockorphan(), zeroing sksocket, and frees the struct socket.  The accept-side code either reads NULL through sksocket 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->hrfile, 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 acceptdoit reaching FDPREPARE() takes the !removepending() branch in handshakereqcancel() and drops hrfile before the accept side takes its own reference.  Hand off an additional file reference inside handshakereqnext(), under hnlock, so the accept side operates on a reference that no concurrent handshakereqcancel() can revoke.  FDPREPARE() consumes that handed-off reference, either by transferring it to the new fd in fdpublish() 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.