netdev - Re: [PATCH net-next] tcp: do not allow to connect with the four-tuple symmetry socket

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+tcoBVYE0+TeRW8AkmxXAYuJ04Za3XmZXD5T5R=LxqXRWzbw@mail.gmail.com>
Date: Mon, 19 Aug 2024 17:31:26 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Kuniyuki Iwashima <kuniyu@...zon.com>, 0x7f454c46@...il.com, davem@...emloft.net, 
	dima@...sta.com, dsahern@...nel.org, kernelxing@...cent.com, kuba@...nel.org, 
	ncardwell@...gle.com, netdev@...r.kernel.org, pabeni@...hat.com, 
	Florian Westphal <fw@...len.de>, Pablo Neira Ayuso <pablo@...filter.org>
Subject: Re: [PATCH net-next] tcp: do not allow to connect with the four-tuple
 symmetry socket

On Mon, Aug 19, 2024 at 5:18 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Mon, Aug 19, 2024 at 11:02 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> >
> > Hello Eric,
> >
> > On Mon, Aug 19, 2024 at 3:30 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > >
> > > On Mon, Aug 19, 2024 at 2:27 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > >
> > > > On Mon, Aug 19, 2024 at 7:48 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > > >
> > > > > Hello Kuniyuki,
> > > > >
> > > > > On Mon, Aug 19, 2024 at 2:49 AM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
> > > > > >
> > > > > > From: Jason Xing <kerneljasonxing@...il.com>
> > > > > > Date: Sun, 18 Aug 2024 21:50:51 +0800
> > > > > > > On Sun, Aug 18, 2024 at 1:16 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > > > > > >
> > > > > > > > On Sun, Aug 18, 2024 at 12:25 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > > > > > > >
> > > > > > > > > From: Jason Xing <kernelxing@...cent.com>
> > > > > > > > >
> > > > > > > > > Four-tuple symmetry here means the socket has the same remote/local
> > > > > > > > > port and ipaddr, like this, 127.0.0.1:8000 -> 127.0.0.1:8000.
> > > > > > > > > $ ss -nat | grep 8000
> > > > > > > > > ESTAB      0      0          127.0.0.1:8000       127.0.0.1:8000
> > > > > > >
> > > > > > > Thanks to the failed tests appearing in patchwork, now I'm aware of
> > > > > > > the technical term called "self-connection" in English to describe
> > > > > > > this case. I will update accordingly the title, body messages,
> > > > > > > function name by introducing "self-connection" words like this in the
> > > > > > > next submission.
> > > > > > >
> > > > > > > Following this clue, I saw many reports happening in these years, like
> > > > > > > [1][2]. Users are often astonished about this phenomenon and lost and
> > > > > > > have to find various ways to workaround it. Since, in my opinion, the
> > > > > > > self-connection doesn't have any advantage and usefulness,
> > > > > >
> > > > > > It's useful if you want to test simultaneous connect (SYN_SENT -> SYN_RECV)
> > > > > > path as you see in TCP-AO tests.  See RFC 9293 and the (!ack && syn) case
> > > > > > in tcp_rcv_synsent_state_process().
> > > > > >
> > > > > >   https://www.rfc-editor.org/rfc/rfc9293.html#section-3.5-7
> > > > >
> > > > > Yes, I noticed this one: self-connection is one particular case among
> > > > > simultaneously open cases. Honestly, it's really strange that client
> > > > > and server uses a single socket.
> > > > >
> > > > > >
> > > > > > So you can't remove self-connect functionality, the recent main user is
> > > > > > syzkaller though.
> > > > >
> > > > > Ah, thanks for reminding me. It seems that I have to drop this patch
> > > > > and there is no good way to resolve the issue in the kernel.
> > > > >
> > > >
> > > > Can we introduce one sysctl knob to control it since we can tell there
> > > > are many user reports/complaints through the internet? Default setting
> > > > of the new knob is to allow users to connect to itself like right now,
> > > > not interfering with many years of habits, like what the test tools
> > > > currently use.
> > > >
> > > > Can I give it a shot?
> > >
> > > No you can not.
> >
> > May I ask why? Is it because self-connection adheres to the
> > simultaneously open part in RFC 9293?
>
> This will break some user programs, obviously.

I agree. It'a headache.

>
> I will ask you the opposite : What RFC prevents the current situation ?

Not really, actually. The reason why I wrote the patch is because it
indeed happened.

>
> >
> > I feel this case is very particular, not explained well in the RFC.
> > Usually, we don't consider one socket to act as client and server
> > unless in debug or test circumstances. As you can see, some people
> > have encountered the issue for a long time.
>
> Can you provide links to the issues ? How can a programmer hit this
> using standard and documented ways (passive, active flows) ?
>

I've listed some of them in the previous discussion through googling
"tcp self connection" or something like that. Let me copy here:
[1]: https://adil.medium.com/what-is-tcp-self-connect-issue-be7d7b5f9f59
[2]: https://stackoverflow.com/questions/5139808/tcp-simultaneous-open-and-self-connect-prevention

After investigating such an issue more deeply in the customers'
machines, the main reason why it can happen is the listener exits
while another thread starts to connect, which can cause
self-connection, even though the chance is slim. Later, the listener
tries to listen and for sure it will fail due to that single
self-connection.

Thanks,
Jason