linux-kernel - Re: [PATCH bpf-next v2 3/6] net: remove duplicate reuseport

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: <20230614165244.59782-1-kuniyu@amazon.com>
Date:   Wed, 14 Jun 2023 09:52:44 -0700
From:   Kuniyuki Iwashima <kuniyu@...zon.com>
To:     <lmb@...valent.com>
CC:     <andrii@...nel.org>, <ast@...nel.org>, <bpf@...r.kernel.org>,
        <daniel@...earbox.net>, <davem@...emloft.net>,
        <dsahern@...nel.org>, <edumazet@...gle.com>, <haoluo@...gle.com>,
        <hemanthmalla@...il.com>, <joe@...d.net.nz>,
        <john.fastabend@...il.com>, <jolsa@...nel.org>,
        <kpsingh@...nel.org>, <kuba@...nel.org>, <kuniyu@...zon.com>,
        <linux-kernel@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
        <martin.lau@...ux.dev>, <mykolal@...com>, <netdev@...r.kernel.org>,
        <pabeni@...hat.com>, <sdf@...gle.com>, <shuah@...nel.org>,
        <song@...nel.org>, <willemdebruijn.kernel@...il.com>, <yhs@...com>
Subject: Re: [PATCH bpf-next v2 3/6] net: remove duplicate reuseport_lookup functions

From: Lorenz Bauer <lmb@...valent.com>
Date: Wed, 14 Jun 2023 16:25:05 +0100
> On Tue, Jun 13, 2023 at 7:57 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
> >
> >                         else {
> >                                 result = sk;
> >                         }
> >
> > The assignment to result below is buggy.  Let's say SO_REUSEPROT group
> > have TCP_CLOSE and TCP_ESTABLISHED sockets.
> 
> I'm not very familiar with SO_REUSEPORT, I assumed (incorrectly
> probably) that such a group would only ever have TCP_CLOSE in UDP case
> and TCP_LISTENING in TCP case. Can you explain how I could end up in
> this situation?

When we call conenct() for UDP socket in SO_REUSEPORT group, the state
is changed from TCP_CLOSE to TCP_ESTABLISHED in __ip4_datagram_connect(),
and the socket remains in the group.

That's why we check TCP_ESTABLISHED in reuseport_select_sock_by_hash()
that is always false for TCP but true for UDP in the case above.