On Fri, 20 Feb 2015, Devin Heitmueller wrote: > Hi there, > > I've been trying to track down some memory corruption in my driver for > the HVR-950q related to dequeueing of ISOC URBs when shutting down the > stream. I enabled SLUB poisoning, and I'm seeing a use-after-free > condition in the EHCI driver. See below. > > Based on my read of the stack, it looks like the IRQ handler comes > along and tries to access the URB eba088f0 *after* I've already killed > it. In fact, I can see that the usb_kill_urb() call for that URB has > returned, since it's already moved onto killing the next URB in the > list when the crash occurs. My assumption would have to be that the > URB wasn't properly removed from the ISOC schedule. ... > [ 540.930062] au0828/0: stop_urb_transfer() > [ 540.930069] au0828/0: killing urb eba08340 > [ 540.933270] au0828/0: killing urb eba088f0 > [ 540.933293] au0828/0: killing urb f431ca90 > [ 540.936242] BUG: unable to handle kernel paging request at 6b6b6b6f > [ 540.936445] IP: [<c149bc1e>] usb_hcd_unlink_urb_from_ep+0x1e/0x40 ... > [ 540.939621] EIP: 0060:[<c149bc1e>] EFLAGS: 00210046 CPU: 0 > [ 540.939758] EIP is at usb_hcd_unlink_urb_from_ep+0x1e/0x40 > [ 540.939894] EAX: eba08904 EBX: eba088f0 ECX: 6b6b6b6b EDX: 6b6b6b6b > [ 540.940046] ESI: eba088f0 EDI: f6831860 EBP: f7009e50 ESP: f7009e4c The fact that esi contains 0xeba088f0 is indeed suspicious. > [ 540.940197] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > [ 540.940329] CR0: 8005003b CR2: 6b6b6b6f CR3: 2ba72000 CR4: 000007f0 > [ 540.940480] Stack: > [ 540.940534] f6831a64 f7009e68 c14ae94a ffffff8d eb96c8a0 eb96c39c > ef9d1d90 f7009ecc > [ 540.940773] c14af863 2b96c5a0 00000000 00200082 000f4240 00000007 > f68319e0 f7009ea0 > [ 540.941010] c1075a26 000f4240 03010000 f685d960 eb96c8a0 ef9d1da0 > 00000001 f68319a8 > [ 540.941247] Call Trace: > [ 540.941322] [<c14ae94a>] ehci_urb_done+0x4a/0x90 > [ 540.941443] [<c14af863>] qh_completions+0x203/0x580 > [ 540.941573] [<c1075a26>] ? hrtimer_start_range_ns+0x26/0x30 > [ 540.941720] [<c14b0738>] end_unlink_async+0x108/0x1f0 > [ 540.941852] [<c14b3141>] ehci_irq+0xf1/0x430 But the fact that the call stack passes through qh_completions and ehci_unlink_async means that the URB in question is _not_ isochronous (or interrupt for that matter). Does that help? If you want to trace things in greater detail, look at the value of urb->use_count at various points. usb_kill_urb won't return until the value reaches 0, which should not occur until well after usb_hcd_unlink_urb_from_ep returns. Alan Stern -- 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
