netdev - 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL+tcoBjoz3SLBJDDYmet4F6iBybkj3Up18ckTD8tsH0J1HO_g@mail.gmail.com>
Date: Wed, 14 Aug 2024 12:56:29 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Lorenzo Colitti <lorenzo@...gle.com>
Cc: Eric Dumazet <edumazet@...gle.com>, Xueming Feng <kuro@...oa.me>, 
	"David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org, 
	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, 
	Maciej Żenczykowski <zenczykowski@...il.com>
Subject: Re: [PATCH net] tcp: fix forever orphan socket caused by tcp_abort

On Wed, Aug 14, 2024 at 12:43 PM Lorenzo Colitti <lorenzo@...gle.com> wrote:
>
> On Mon, Aug 5, 2024 at 4:23 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > > Each time we call inet_csk_destroy_sock(), we must make sure we've
> > > already set the state to TCP_CLOSE. Based on this, I think we can use
> > > this as an indicator to avoid calling twice to destroy the socket.
> >
> > I do not think this will work.
> >
> > With this patch, a listener socket will not get an error notification.
> >
> > Ideally we need tests for this seldom used feature.
>
> FWIW there is a fair amount of test coverage here:
>
> https://cs.android.com/android/platform/superproject/main/+/main:kernel/tests/net/test/sock_diag_test.py
>
> though unfortunately they don't pass on unmodified kernels (I didn't
> look into why - maybe Maciej knows). I ran the tests on the "v2-ish
> patch" and they all passed except for a test that expects that
> SOCK_DESTROY on a FIN_WAIT1 socket does nothing. That seems OK because
> it's the thing your patch is trying to fix.
>
> Just to confirm - it's OK to send a RST on a connection that's already
> in FIN_WAIT1 state? Is that allowed by the RFC?

I think so. Please take a look at the following link which tells us
whether we should send an RST:

ABORT Call

    ESTABLISHED STATE
    FIN-WAIT-1 STATE
    FIN-WAIT-2 STATE
    CLOSE-WAIT STATE

      Send a reset segment:

        <SEQ=SND.NXT><CTL=RST>

      All queued SENDs and RECEIVEs should be given "connection reset"
      notification; all segments queued for transmission (except for the
      RST formed above) or retransmission should be flushed, delete the
      TCB, enter CLOSED state, and return.

https://www.ietf.org/rfc/rfc793.txt#:~:text=Specification%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20ABORT%20Call-,ABORT%20Call,-CLOSED%20STATE%20(i

Thanks,
Jason