Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAN+4W8hMpL3+vNOrBBRw01tD6OxQ-Yy8OWpq9nRtiyjm0GgE4g@mail.gmail.com>
 <20230809155538.67000-1-kuniyu@amazon.com>
In-Reply-To: <20230809155538.67000-1-kuniyu@amazon.com>
From:   Lorenz Bauer <lmb@isovalent.com>
Date:   Wed, 9 Aug 2023 17:55:02 +0100
Message-ID: <CAN+4W8h44UdLRT+QLdh2rNeiKg0AkPAuGtYuXOgtFzvT2kHsWg@mail.gmail.com>
Subject: Re: [PATCH bpf-next] net: Fix slab-out-of-bounds in inet[6]_steal_sock
To:     Kuniyuki Iwashima <kuniyu@amazon.com>
Cc:     bpf@vger.kernel.org, daniel@iogearbox.net, davem@davemloft.net,
        edumazet@google.com, kuba@kernel.org, linux-kernel@vger.kernel.org,
        martin.lau@kernel.org, martin.lau@linux.dev, memxor@gmail.com,
        netdev@vger.kernel.org, pabeni@redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Aug 9, 2023 at 4:56=E2=80=AFPM Kuniyuki Iwashima <kuniyu@amazon.com=
> wrote:
>
> > Things we could do if necessary:
> > 1. Reset the flag in inet_csk_clone_lock like we do for SOCK_RCU_FREE
>
> I think we can't do this as sk_reuseport is inherited to twsk and used
> in inet_bind_conflict().

Ok, so what kind of state does reuseport carry in the various states then?

TCP_LISTEN: sk_reuseport && sk_reuseport_cb
TCP_ESTABLISHED: sk_reuseport && !sk_reuseport_cb
TCP_TIME_WAIT: sk_reuseport && !sk_reuseport_cb

Where is sk_reuseport_cb cleared? On clone? Or not at all?

> > 2. Duplicate the cb check into inet[6]_steal_sock
>
> or 3. Add sk_fullsock() test ?

I guess this would be in addition to the convoluted series of checks
I've removed in this patch?