On Thu, Mar 23, 2017 at 4:22 PM, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: >> On Thu, 23 Mar 2017, Dmitry Vyukov wrote: >> >>> > 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? >> >> I don't think so. The URB gets allocated and deallocated separately >> for each call. You can see this very plainly by reading the source >> code for usb_internal_control_msg() and usb_start_wait_urb(). >> >> It's possible that the same memory location was allocated and >> deallocated for two different calls at different times. That wouldn't >> fool syzkaller, would it? > > > Generally it does not fool KASAN because of heap memory quarantine. > I will take a closer look tomorrow. > Thanks for looking into this. The bug looks real to me and it can be easily reproduced by executing: mmap(&(0x7f0000000000/0xfff000)=nil, (0xfff000), 0x3, 0x32, 0xffffffffffffffff, 0x0) syz_open_dev$usb(&(0x7f0000001000-0x15)="2f6465762f6275732f7573622f3030232f30302300", 0x1ff, 0x200) syz_open_dev$usb(&(0x7f0000002000-0x15)="2f6465762f6275732f7573622f3030232f30302300", 0x3f, 0x0) and failing 7-th malloc in the first one, this one: kzalloc include/linux/slab.h:663 [inline] rh_call_control drivers/usb/core/hcd.c:522 [inline] >From the report: (from the failure stack) kmalloc in rh_call_control fails, and it straight returns -ENOMEM without calling usb_hcd_unlink_urb_from_ep(hcd, urb) leaving urb linked into hcd (and that's probably the root problem) consequently: rh_urb_enqueue return -ENOMEM usb_hcd_submit_urb does INIT_LIST_HEAD(&urb->urb_list), but the urb is still linked, so we got corrupted list (from the free stack) eventually usb_start_wait_urb frees the still linked urb by calling usb_free_urb (form the use-after-free stack) the subsequent open links a new urb into the corrupted list in usb_hcd_link_urb_to_ep bang! -- 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
