From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753689AbbLRWCd (ORCPT ); Fri, 18 Dec 2015 17:02:33 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:56896 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752459AbbLRWCa (ORCPT ); Fri, 18 Dec 2015 17:02:30 -0500 Date: Fri, 18 Dec 2015 22:02:04 +0000 From: One Thousand Gnomes To: David Miller Cc: dvyukov@google.com, ajk@comnets.uni-bremen.de, linux-hams@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, jslaby@suse.com, syzkaller@googlegroups.com, kcc@google.com, glider@google.com, sasha.levin@oracle.com, edumazet@google.com Subject: Re: use-after-free in sixpack_close Message-ID: <20151218220204.6faf8e93@lxorguk.ukuu.org.uk> In-Reply-To: <20151218.155954.26632223306803039.davem@davemloft.net> References: <20151217114104.6946d72b@lxorguk.ukuu.org.uk> <20151217.160532.999129498473749695.davem@davemloft.net> <20151217234739.651e7c5b@lxorguk.ukuu.org.uk> <20151218.155954.26632223306803039.davem@davemloft.net> Organization: Intel Corporation X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Also you are at the point the tty is closing so the net device may be > > active. Don't you need to netif_stop_queue() or defer the buffer > > kfrees until after the network device is unregistered so you don't pee > > into free memory if you have a transmit occurring ? > > I'm pretty sure that's what the semaphore down above this sequence is > accomplishing. But if we do need the netif_stop_queue() let's do that > as a separate patch. Follow the code path for sp_xmit(). If sp_xmit is called it digs out sp from the ndetdev, locks sp->lock and stops the queue then calls sp_encaps which touches sp->xbuff. So if one thread of execution hits sp_xmit and another closes the ldisc at just the wrong moment then we have no protection. Alan