Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753194AbdCBF1N (ORCPT ); Thu, 2 Mar 2017 00:27:13 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:35530 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750959AbdCBF1A (ORCPT ); Thu, 2 Mar 2017 00:27:00 -0500 MIME-Version: 1.0 In-Reply-To: References: From: Cong Wang Date: Wed, 1 Mar 2017 21:25:54 -0800 Message-ID: Subject: Re: net: use-after-free in neigh_timer_handler/sock_wfree To: Eric Dumazet Cc: Dmitry Vyukov , David Miller , netdev , LKML , syzkaller , Alexey Kuznetsov , James Morris Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 918 Lines: 22 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.