Hi Felipe,

On Fri, Mar 23, 2018 at 10:05:33AM -0700, Jack Pham wrote:

dwc3_ep_dequeue() waits for completion of End Transfer command using wait_event_lock_irq(), which will release the dwc3->lock while waiting and reacquire after completion. This allows a potential race condition with ep_disable() which also removes all requests from started_list and pending_list. The check for NULL r->trb should catch this but currently it exits to the wrong 'out1' label which calls dwc3_gadget_giveback(). Since its list entry was already removed, if CONFIG_DEBUG_LIST is enabled a 'list_del corruption' bug is thrown since its next/prev pointers are already LIST_POISON1/2. If r->trb is NULL it should simply exit to 'out0'.

Fixes: cf3113d893d4 ("usb: dwc3: gadget: properly increment dequeue pointer on ep_dequeue")

Upon taking a second look at this patch, and noting the subject of the Fixes tag here, one side effect of this fix is that dep->queued_requests won't get decremented. I see this is a counter for tracing purposes so probably doesn't affect function. But it begs the question of whether dwc3_remove_requests() as called from __dwc3_gadget_ep_disable() should have decremented this counter or even zeroed it out completely?

	if (!r->trb)

• 		goto out1;
  

• 		goto out0;
  

Thanks, Jack