Re: [PATCH net 5/7] net/handshake: hand off the pinned file reference to accept_doit

On 5/18/26 20:24, Chuck Lever wrote:
> From: Chuck Lever <[email protected]>
> 
> handshake_req_next() removes the request from the per-net
> pending list and drops hn_lock before handshake_nl_accept_doit()
> reads req->hr_sk->sk_socket and dereferences sock->file (once in
> FD_PREPARE() and again in get_file()).  In that window a
> consumer running tls_handshake_cancel() followed by sockfd_put()
> (svc_sock_free) or __fput_sync() (xs_reset_transport) releases
> sock->file.  sock_release() then runs sock_orphan(), 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 sock_hold() does not prevent this.  sk_refcnt
> 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->hr_sk->sk_socket->file.
> Pinning on its own is not sufficient: a consumer that cancels
> between handshake_req_next() returning and accept_doit reaching
> FD_PREPARE() takes the !remove_pending() branch in
> handshake_req_cancel() and drops hr_file before the accept side
> takes its own reference.  Hand off an additional file reference
> inside handshake_req_next(), under hn_lock, so the accept side
> operates on a reference that no concurrent handshake_req_cancel()
> 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
> get_file() that previously balanced FD_PREPARE() is therefore
> redundant and goes away.
> 
> Update handshake_req_cancel_test2 and _test3 to simulate the
> FD_PREPARE() consumption with an fput() so the kunit file-count
> assertions stay balanced.
> 
> Reported-by: Chris Mason <[email protected]>
> Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests")
> Signed-off-by: Chuck Lever <[email protected]>
> ---
>   net/handshake/handshake-test.c |  8 ++++++++
>   net/handshake/netlink.c        |  7 ++-----
>   net/handshake/request.c        | 18 ++++++++++++++++++
>   3 files changed, 28 insertions(+), 5 deletions(-)
> 
I _think_ this should fix the issue I had reported about a kernel oops 
in __sys_recvfrom() in tlshd.
Which has all the symptoms described here.
So glad that it's been addressed.

Reviewed-by: Hannes Reinecke <[email protected]>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
[email protected]                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich