From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Fastabend Subject: Re: [PATCH bpf-next] bpf: prevent non-IPv4 socket to be added into sock hash Date: Fri, 1 Jun 2018 11:40:35 -0700 Message-ID: <0fdad75a-851c-28d4-33ed-6a10f764ab17@gmail.com> References: <20180530212928.190650-1-tracywwnj@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Wei Wang , netdev , Willem de Bruijn To: Eric Dumazet Return-path: Received: from mail-it0-f66.google.com ([209.85.214.66]:53772 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752268AbeFASks (ORCPT ); Fri, 1 Jun 2018 14:40:48 -0400 Received: by mail-it0-f66.google.com with SMTP id a195-v6so2846427itd.3 for ; Fri, 01 Jun 2018 11:40:48 -0700 (PDT) In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 06/01/2018 12:56 AM, John Fastabend wrote: > On 05/31/2018 06:00 PM, Eric Dumazet wrote: >> On Thu, May 31, 2018 at 7:32 PM John Fastabend wrote: >>> >>> >>> Hi Wei, >>> >>> Thanks for the report and fix. It would be better to fix the >>> root cause so that IPv6 works as intended. >>> >>> I'm testing the following now, >>> >>> Author: John Fastabend >>> Date: Thu May 31 14:38:59 2018 -0700 >>> >>> sockmap: fix crash when ipv6 sock is added by adding support for IPv6 >>> >>> Apparently we had a testing escape and missed IPv6. This fixes a crash >>> where we assign tcp_prot to IPv6 sockets instead of tcpv6_prot. >>> >>> Signed-off-by: John Fastabend >>> >> >> Hi John >> >> In any case, please forward correct attribution for Wei's work, and >> syzbot 'Reported-by' > > Will send update with tags in a moment. > >> >> Are you sure you are handling IPv4 mapped in IPv6 sockets as well ? >> > > No, will look into it. Although I didn't see any code to handle it > in the ./net/tls case either so if there is some issue with this it > could possibly exist in both ULPs. I guess if ipv4 mapped ipv6 > changes prot or callbacks then we could stomp on it. > Will need a v2 to address this, by adding a check to only work on ESTABLISHED sockets we resolve this issue and the one noted in the TLS ULP side as well. Thanks a lot Eric.