lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 8 Feb 2017 18:36:07 +0100
From:   Dmitry Vyukov <>
To:     Eric Dumazet <>
Cc:     Eric Dumazet <>,
        David Miller <>,
        Alexey Kuznetsov <>,
        James Morris <>,
        Hideaki YOSHIFUJI <>,
        Patrick McHardy <>,
        netdev <>,
        LKML <>,
        syzkaller <>
Subject: Re: net: use-after-free in tw_timer_handler

On Tue, Jan 24, 2017 at 4:52 PM, Eric Dumazet <> wrote:
> On Tue, Jan 24, 2017 at 7:06 AM, Dmitry Vyukov <> wrote:
>>> This code was changed a long time ago :
>>> So I suspect a recent patch broke the logic.
>>> You might start a bisection :
>>> I would check if 4.7 and 4.8 trigger the issue you noticed.
>> It happens with too low rate for bisecting (few times per day). I
>> could add some additional checks into code, but I don't know what
>> checks could be useful.
> If you can not tell if 4.7 and/or 4.8 have the problem, I am not sure
> we are able to help.

There are also chances that the problem is older.

Looking at the code, this part of inet_twsk_purge looks fishy:

285                         if (unlikely((tw->tw_family != family) ||
286                                      atomic_read(&twsk_net(tw)->count))) {

It uses net->count == 0 check to find the right sockets. But what if
there are several nets with count == 0 in flight, can't there be
several inet_twsk_purge calls running concurrently freeing each other
sockets? If so it looks like inet_twsk_purge can call
inet_twsk_deschedule_put twice for a socket. Namely, two calls for
different nets discover the socket, check that net->count==0 and both
call inet_twsk_deschedule_put. Shouldn't we just give inet_twsk_purge
net that it needs to purge?

The second issue that I noticed is that tw_refcnt is set to 4 _after_
we schedule the timer. The timer will probably won't fire before we
set tw_refcnt, but if it somehow does it will corrupt the ref count. I
don't think that it's what I am seeing, though. More likely it's the
first issues (if it's real).

Does it make any sense?

Powered by blists - more mailing lists