[PATCH net 5/7] net/handshake: hand off the pinned file reference to accept_doit
Hannes Reinecke
hare at suse.de
Tue May 19 00:59:42 PDT 2026
On 5/18/26 20:24, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever at oracle.com>
>
> 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 <clm at meta.com>
> Fixes: 3b3009ea8abb ("net/handshake: Create a NETLINK service for handling handshake requests")
> Signed-off-by: Chuck Lever <chuck.lever at oracle.com>
> ---
> 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 <hare at kernel.org>
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare at suse.de +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
More information about the Linux-nvme
mailing list