linux-kernel - Re: [PATCH net] tcp: fix forever orphan socket caused by tcp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL+tcoAyx56CCDk3hyYzR_K_L=fSNsQYy=d88Qv4eQA0GfJD7A@mail.gmail.com>
Date: Fri, 9 Aug 2024 14:56:39 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Xueming Feng <kuro@...oa.me>
Cc: "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org, 
	Eric Dumazet <edumazet@...gle.com>, Lorenzo Colitti <lorenzo@...gle.com>, 
	Neal Cardwell <ncardwell@...gle.com>, Yuchung Cheng <ycheng@...gle.com>, 
	Soheil Hassas Yeganeh <soheil@...gle.com>, David Ahern <dsahern@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] tcp: fix forever orphan socket caused by tcp_abort

Hello Xueming,

[...]
>
> Below is the patch changed according to your advice. The test now happens
> after the lock_sock and will return -ENOENT if the socket has already been
> closed by someone else.
>
> About the tests, I have some script that helps me to test the situation.
> But after reading about KUnit framework, I could not find any current
> example for TCP testing. Could anyone enlighten me?
>
>
> Signed-off-by: Xueming Feng <kuro@...oa.me>
> ---
>  net/ipv4/tcp.c | 18 +++++++++++-------
>  1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index e03a342c9162..831a18dc7aa6 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -4637,6 +4637,13 @@ int tcp_abort(struct sock *sk, int err)
>                 /* Don't race with userspace socket closes such as tcp_close. */
>                 lock_sock(sk);
>
> +       /* Avoid closing the same socket twice. */
> +       if (sk->sk_state == TCP_CLOSE) {
> +               if (!has_current_bpf_ctx())
> +                       release_sock(sk);
> +               return -ENOENT;
> +       }
> +
>         if (sk->sk_state == TCP_LISTEN) {
>                 tcp_set_state(sk, TCP_CLOSE);
>                 inet_csk_listen_stop(sk);
> @@ -4646,16 +4653,13 @@ int tcp_abort(struct sock *sk, int err)
>         local_bh_disable();
>         bh_lock_sock(sk);
>
> -       if (!sock_flag(sk, SOCK_DEAD)) {
> -               if (tcp_need_reset(sk->sk_state))
> -                       tcp_send_active_reset(sk, GFP_ATOMIC,
> -                                             SK_RST_REASON_NOT_SPECIFIED);
> -               tcp_done_with_error(sk, err);
> -       }
> +       if (tcp_need_reset(sk->sk_state))
> +               tcp_send_active_reset(sk, GFP_ATOMIC,
> +                                     SK_RST_REASON_NOT_SPECIFIED);
> +       tcp_done_with_error(sk, err);
>
>         bh_unlock_sock(sk);
>         local_bh_enable();
> -       tcp_write_queue_purge(sk);
>         if (!has_current_bpf_ctx())
>                 release_sock(sk);
>         return 0;
> --

I checked the RFC 793 and reckoned returning 'ENOENT' is similar to
'error: connection does not exist', which can show enough information
to the user.

So I think you could try to cook a v2 patch officially.

Thanks,
Jason