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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 1 Mar 2017 21:25:54 -0800
From:   Cong Wang <>
To:     Eric Dumazet <>
Cc:     Dmitry Vyukov <>,
        David Miller <>,
        netdev <>,
        LKML <>,
        syzkaller <>,
        Alexey Kuznetsov <>,
        James Morris <>
Subject: Re: net: use-after-free in neigh_timer_handler/sock_wfree

On Wed, Mar 1, 2017 at 3:15 PM, Eric Dumazet <> wrote:
> On Wed, Mar 1, 2017 at 3:09 PM, Cong Wang <> 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