lkml.org 
[lkml]   [2017]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: net: use-after-free in tw_timer_handler
    From
    Date
    On Wed, 2017-02-08 at 19:55 +0100, Dmitry Vyukov wrote:
    > On Wed, Feb 8, 2017 at 6:58 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
    > > On Wed, 2017-02-08 at 18:36 +0100, Dmitry Vyukov wrote:
    > >> On Tue, Jan 24, 2017 at 4:52 PM, Eric Dumazet <edumazet@google.com> wrote:
    > >> > On Tue, Jan 24, 2017 at 7:06 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
    > >> >>>
    > >> >>> This code was changed a long time ago :
    > >> >>>
    > >> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ed2e923945892a8372ab70d2f61d364b0b6d9054
    > >> >>>
    > >> >>> 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?
    > >
    > > Yes, atomic_read() is not a proper sync point.
    >
    > Do you mean that it does not include read barrier?
    > I more mean that we can call inet_twsk_deschedule_put twice for the same socket.

    I meant that this code assumed RTNL being held.

    This might not be the case now, after some old change.


    \
     
     \ /
      Last update: 2017-02-08 20:19    [W:3.350 / U:0.192 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site