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 <lore...@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)
