lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 23 Mar 2017 10:34:11 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Dmitry Vyukov <dvyukov@...gle.com>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        <mathias.nyman@...ux.intel.com>, <baoyou.xie@...aro.org>,
        <peter.chen@....com>, <wulf@...k-chips.com>,
        <wsa-dev@...g-engineering.com>, <javier@....samsung.com>,
        <chris.bainbridge@...il.com>, USB list <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ