From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH net] net: diag: Don't double-free TCP_NEW_SYN_RECV sockets
 in tcp_abort
Date: Sat, 7 Jul 2018 06:51:07 -0700
Message-ID: <1017e0f1-e7eb-60d3-d6e6-914da1bc9962@gmail.com>
References: <20180707073140.202004-1-lorenzo@google.com>
 <20180707.221146.161981342461262899.davem@davemloft.net>
 <248c63e2-6c6c-9c6e-37c2-4c7218f4899b@cumulusnetworks.com>
 <b3b107e7-3ed9-e0c3-9c11-d91ac6f9f4e5@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: netdev@vger.kernel.org, astrachan@google.com,
        subashab@codeaurora.org
To: David Ahern <dsa@cumulusnetworks.com>,
        David Miller <davem@davemloft.net>, lorenzo@google.com
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pf0-f196.google.com ([209.85.192.196]:45426 "EHLO
        mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752947AbeGGNvJ (ORCPT
        <rfc822;netdev@vger.kernel.org>); Sat, 7 Jul 2018 09:51:09 -0400
Received: by mail-pf0-f196.google.com with SMTP id y24-v6so10565187pfe.12
        for <netdev@vger.kernel.org>; Sat, 07 Jul 2018 06:51:09 -0700 (PDT)
In-Reply-To: <b3b107e7-3ed9-e0c3-9c11-d91ac6f9f4e5@gmail.com>
Content-Language: en-US
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>



On 07/07/2018 06:45 AM, Eric Dumazet wrote:
> 
> 
> On 07/07/2018 06:33 AM, David Ahern wrote:
>> On 7/7/18 7:11 AM, David Miller wrote:
>>> From: Lorenzo Colitti <lorenzo@google.com>
>>> Date: Sat,  7 Jul 2018 16:31:40 +0900
>>>
>>>> Tested: passes Android sock_diag_test.py, which exercises this codepath
>>>
>>> If this Android test case exercises this path, why didn't it trigger
>>> the double free and thus cause this bug to be found much sooner?
>>>
>>
>> wondering the same. How can I get access to sock_diag_test.py?
>>
> 
> I would simply use ss -tKa src :443 command on a live web server ;)
> 
> Note to readers : Do not try that unless you want to kill your server.
> 
>

Here is a packetdrill test :

// Test SOCK_DESTROY on SYN_RECV request sockets
// We use the "ss" socket statistics tool, which uses inet_diag sockets.

// ss -K can be slow
--tolerance_usecs=15000


    0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
   +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
   +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
   +0 bind(3, ..., ...) = 0
   +0 listen(3, 1) = 0

   +0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 2>
   +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>

// ss -K is scary ! Do not mess with the filter or risk killing a lot of flows
   +0 `ss -t -K -n state SYN-RECV src :8080 >/dev/null`

  +.1 < . 1:1(0) ack 1 win 32890
   +0 > R 1:1(0)

// The listener was not killed, but has no available child -> -1 EAGAIN
   +0 accept(3, ..., ...) = -1 EAGAIN (Resource temporarily unavailable)