[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpU7AAVPvvw1921=UJ9E8ktvEo3ONaUkDEeD_yVN5+jwSA@mail.gmail.com>
Date: Wed, 1 Mar 2017 21:25:54 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Dmitry Vyukov <dvyukov@...gle.com>,
David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller <syzkaller@...glegroups.com>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
James Morris <jmorris@...ei.org>
Subject: Re: net: use-after-free in neigh_timer_handler/sock_wfree
On Wed, Mar 1, 2017 at 3:15 PM, Eric Dumazet <edumazet@...gle.com> wrote:
> On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang <xiyou.wangcong@...il.com> wrote:
>
>>
>> But I doubt skb_orphan() is the solution here, shouldn't we just
>> update sk->sk_wmem_alloc with skb->truesize changes?
>
> Is it worth it ? Apart from syszkaller I mean...
>
> We started with something that had a real impact on real workloads.
>
> 158f323b9868b59967ad96957c4ca388161be321 net: adjust skb->truesize in
> pskb_expand_head()
>
> Note that auditing the stack took me a while.
I don't know how sk refcnt could work correctly without making
sk_wmem_alloc correctly. We certainly could just call skb_orphan()
is we don't need skb->sk any more, probably like the frag case,
but for this case, the neigh one, the skb's sitting in neigh->arp_queue
are not going to be freed unless in failed case, therefore skb->sk
should not be orphaned so early.
Powered by blists - more mailing lists