[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP01T74YAkdqNirpc4sCCnK_nwWpYJNcuM94xWDnbHY_Be6o=A@mail.gmail.com>
Date: Wed, 9 Aug 2023 17:28:57 +0530
From: Kumar Kartikeya Dwivedi <memxor@...il.com>
To: Lorenz Bauer <lmb@...valent.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Daniel Borkmann <daniel@...earbox.net>,
Kuniyuki Iwashima <kuniyu@...zon.com>,
Martin KaFai Lau <martin.lau@...nel.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next] net: Fix slab-out-of-bounds in inet[6]_steal_sock
On Wed, 9 Aug 2023 at 14:04, Lorenz Bauer <lmb@...valent.com> wrote:
>
> Kumar reported a KASAN splat in tcp_v6_rcv:
>
> bash-5.2# ./test_progs -t btf_skc_cls_ingress
> ...
> [ 51.810085] BUG: KASAN: slab-out-of-bounds in tcp_v6_rcv+0x2d7d/0x3440
> [ 51.810458] Read of size 2 at addr ffff8881053f038c by task test_progs/226
>
> The problem is that inet[6]_steal_sock accesses sk->sk_protocol without
> accounting for request sockets. I added the check to ensure that we only
> every try to perform a reuseport lookup on a supported socket.
>
> It turns out that this isn't necessary at all. struct sock_common contains
> a skc_reuseport flag which indicates whether a socket is part of a
> reuseport group. inet[6]_lookup_reuseport already check this flag,
> so we can't execute an erroneous reuseport lookup by definition.
>
> Remove the unnecessary assertions to fix the out of bounds access.
>
> Fixes: 9c02bec95954 ("bpf, net: Support SO_REUSEPORT sockets with bpf_sk_assign")
> Reported-by: Kumar Kartikeya Dwivedi <memxor@...il.com>
> Signed-off-by: Lorenz Bauer <lmb@...valent.com>
> ---
Thanks for the fix!
Tested-by: Kumar Kartikeya Dwivedi <memxor@...il.com>
Powered by blists - more mailing lists