On Thu, Mar 23, 2017 at 3:34 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
