Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753418AbdCWOeh (ORCPT ); Thu, 23 Mar 2017 10:34:37 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:54304 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1755897AbdCWOed (ORCPT ); Thu, 23 Mar 2017 10:34:33 -0400 Date: Thu, 23 Mar 2017 10:34:11 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Dmitry Vyukov cc: Greg Kroah-Hartman , , , , , , , , USB list , LKML , syzkaller Subject: Re: usb: use-after-free write in usb_hcd_link_urb_to_ep In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2140 Lines: 65 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? Alan