Alan Stern
unread,Mar 23, 2017, 10:34:13 AM3/23/17Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Dmitry Vyukov, Greg Kroah-Hartman, mathia...@linux.intel.com, baoyo...@linaro.org, peter...@nxp.com, wu...@rock-chips.com, wsa...@sang-engineering.com, jav...@osg.samsung.com, chris.ba...@gmail.com, USB list, LKML, syzkaller
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