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: <20240819175614.14990-1-kuniyu@amazon.com>
Date: Mon, 19 Aug 2024 10:56:14 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <kerneljasonxing@...il.com>
CC: <0x7f454c46@...il.com>, <davem@...emloft.net>, <dima@...sta.com>,
	<dsahern@...nel.org>, <edumazet@...gle.com>, <fw@...len.de>,
	<kernelxing@...cent.com>, <kuba@...nel.org>, <kuniyu@...zon.com>,
	<ncardwell@...gle.com>, <netdev@...r.kernel.org>, <pabeni@...hat.com>,
	<pablo@...filter.org>
Subject: Re: [PATCH net-next] tcp: do not allow to connect with the four-tuple symmetry socket

From: Jason Xing <kerneljasonxing@...il.com>
Date: Mon, 19 Aug 2024 17:41:32 +0800
> On Mon, Aug 19, 2024 at 5:38 PM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> > On Mon, Aug 19, 2024 at 11:32 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> >
> > > 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.
> >
> > This would happen if the range of ephemeral ports include the listening port,
> > which is discouraged.
> 
> Yes.
> 
> >
> > ip_local_reserved_ports is supposed to help.
> 
> Sure, I workarounded it by using this and it worked.
> 
> >
> > This looks like a security issue to me, and netfilter can handle it.
> 
> I have to admit setting netfilter rules for each flow is not a very
> user-friendly way.

I think even netfilter is not needed.

It sounds like the server application needs to implement graceful shutdown.
The server should not release the port if there are on-going clients.  The
server should spin up a new process and use the following to transfer the
remaining connections:

  * FD passing
  * SO_REUSEPORT w/ (net.ipv4.tcp_migrate_req or BPF)

Then, no client can occupy the server's port even without
ip_local_reserved_ports.

But I still recommend using ip_local_reserved_ports unless the server port
is random.