Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

From: Alan Stern <stern@rowland.harvard.edu>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	<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 <linux-usb@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: usb: use-after-free write in usb_hcd_link_urb_to_ep
Date: Thu, 23 Mar 2017 10:34:11 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1703231017500.1558-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <CACT4Y+Y_EUwB_e=0Ot2uMX=-cvyi9DyBso=h+X9EJsamr4x7WQ@mail.gmail.com>

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