Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756268AbdCWOkF (ORCPT ); Thu, 23 Mar 2017 10:40:05 -0400 Received: from mail-vk0-f51.google.com ([209.85.213.51]:35404 "EHLO mail-vk0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755751AbdCWOkC (ORCPT ); Thu, 23 Mar 2017 10:40:02 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Dmitry Vyukov Date: Thu, 23 Mar 2017 15:39:40 +0100 Message-ID: Subject: Re: usb: use-after-free write in usb_hcd_link_urb_to_ep To: Alan Stern Cc: Greg Kroah-Hartman , mathias.nyman@linux.intel.com, baoyou.xie@linaro.org, peter.chen@nxp.com, wulf@rock-chips.com, wsa-dev@sang-engineering.com, javier@osg.samsung.com, chris.bainbridge@gmail.com, USB list , LKML , syzkaller 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: 2456 Lines: 67 On Thu, Mar 23, 2017 at 3:34 PM, Alan Stern wrote: > On Thu, 23 Mar 2017, Dmitry Vyukov wrote: > >> Hello, >> >> I've got the following report while running syzkaller fuzzer on >> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected >> kmalloc failure, most likely it's the root cause. > > I find this bug report puzzling. Maybe I don't understand it > correctly -- it appears that the so-called use-after-free actually > occurs _before_ the memory is deallocated! > >> FAULT_INJECTION: forcing a failure. > Skipping this part. Is it relevant? It seems to refer to a different > memory buffer. > >> ================================================================== >> BUG: KASAN: use-after-free in __list_add_valid+0xc6/0xd0 >> lib/list_debug.c:26 at addr ffff88003c377a20 >> Read of size 8 by task syz-executor7/3348 >> CPU: 3 PID: 3348 Comm: syz-executor7 Not tainted 4.11.0-rc3+ #364 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> Call Trace: > > Here are the revelant pieces of the stack traces. Everything below > these parts is the same, and everything above them is unimportant. > (And everything happened in the same process.) The use-after-free > access occurred within this call: > >> usb_start_wait_urb+0x135/0x320 drivers/usb/core/message.c:56 >> usb_internal_control_msg drivers/usb/core/message.c:100 [inline] > > > Here's where the allocation call occurred: > >> Allocated: >> PID = 3348 > ... >> usb_internal_control_msg drivers/usb/core/message.c:93 [inline] > > > And here's where the buffer was deallocated: > >> Freed: >> PID = 3348 > ... >> usb_start_wait_urb+0x234/0x320 drivers/usb/core/message.c:78 >> usb_internal_control_msg drivers/usb/core/message.c:100 [inline] > > Putting these together: > > The memory was allocated in usb_internal_control_msg() line 93. > The later events occurred within the call in line 100 to > usb_start_wait_urb(). > > The invalid access occurred within usb_start_wait_urb() line 56. > > The memory was deallocated within usb_start_wait_urb() line 78. > > Since these routines don't involve any loops or backward jumps, this > says that the invalid access occurred before the memory was > deallocated! So why is it reported as a problem? My first guess would be that pid 3348 did 2 calls to open and the urb was somehow referenced across these calls. Is it possible?