1. 03 7月, 2021 1 次提交
    • J
      usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL · 3a56871d
      Jack Pham 提交于
      stable inclusion
      from stable-5.10.44
      commit 851dee5a5da56564a70290713aee665403bb0b24
      bugzilla: 109295
      CVE: NA
      
      --------------------------------
      
      commit 03715ea2 upstream.
      
      There exists a possible scenario in which dwc3_gadget_init() can fail:
      during during host -> peripheral mode switch in dwc3_set_mode(), and
      a pending gadget driver fails to bind.  Then, if the DRD undergoes
      another mode switch from peripheral->host the resulting
      dwc3_gadget_exit() will attempt to reference an invalid and dangling
      dwc->gadget pointer as well as call dma_free_coherent() on unmapped
      DMA pointers.
      
      The exact scenario can be reproduced as follows:
       - Start DWC3 in peripheral mode
       - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs)
       - Run FunctionFS userspace application (open EPs, write descriptors, etc)
       - Bind gadget driver to DWC3's UDC
       - Switch DWC3 to host mode
         => dwc3_gadget_exit() is called. usb_del_gadget() will put the
      	ConfigFS driver instance on the gadget_driver_pending_list
       - Stop FunctionFS application (closes the ep files)
       - Switch DWC3 to peripheral mode
         => dwc3_gadget_init() fails as usb_add_gadget() calls
      	check_pending_gadget_drivers() and attempts to rebind the UDC
      	to the ConfigFS gadget but fails with -19 (-ENODEV) because the
      	FFS instance is not in FFS_ACTIVE state (userspace has not
      	re-opened and written the descriptors yet, i.e. desc_ready!=0).
       - Switch DWC3 back to host mode
         => dwc3_gadget_exit() is called again, but this time dwc->gadget
      	is invalid.
      
      Although it can be argued that userspace should take responsibility
      for ensuring that the FunctionFS application be ready prior to
      allowing the composite driver bind to the UDC, failure to do so
      should not result in a panic from the kernel driver.
      
      Fix this by setting dwc->gadget to NULL in the failure path of
      dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out
      unless the gadget pointer is valid.
      
      Fixes: e81a7018 ("usb: dwc3: allocate gadget structure dynamically")
      Cc: <stable@vger.kernel.org>
      Reviewed-by: NPeter Chen <peter.chen@kernel.org>
      Signed-off-by: NJack Pham <jackp@codeaurora.org>
      Link: https://lore.kernel.org/r/20210528160405.17550-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Acked-by: NWeilong Chen <chenweilong@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      3a56871d
  2. 15 6月, 2021 1 次提交
  3. 03 6月, 2021 7 次提交
  4. 22 4月, 2021 1 次提交
  5. 13 4月, 2021 2 次提交
  6. 09 4月, 2021 2 次提交
  7. 27 1月, 2021 2 次提交
  8. 02 10月, 2020 19 次提交
  9. 24 9月, 2020 2 次提交
    • T
      usb: dwc3: gadget: END_TRANSFER before CLEAR_STALL command · d97c78a1
      Thinh Nguyen 提交于
      According the programming guide (for all DWC3 IPs), when the driver
      handles ClearFeature(halt) request, it should issue CLEAR_STALL command
      _after_ the END_TRANSFER command completes. The END_TRANSFER command may
      take some time to complete. So, delay the ClearFeature(halt) request
      control status stage and wait for END_TRANSFER command completion
      interrupt. Only after END_TRANSFER command completes that the driver
      may issue CLEAR_STALL command.
      
      Cc: stable@vger.kernel.org
      Fixes: cb11ea56 ("usb: dwc3: gadget: Properly handle ClearFeature(halt)")
      Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      d97c78a1
    • T
      usb: dwc3: gadget: Resume pending requests after CLEAR_STALL · c503672a
      Thinh Nguyen 提交于
      The function driver may queue new requests right after halting the
      endpoint (i.e. queue new requests while the endpoint is stalled).
      There's no restriction preventing it from doing so. However, dwc3
      currently drops those requests after CLEAR_STALL. The driver should only
      drop started requests. Keep the pending requests in the pending list to
      resume and process them after the host issues ClearFeature(Halt) to the
      endpoint.
      
      Cc: stable@vger.kernel.org
      Fixes: cb11ea56 ("usb: dwc3: gadget: Properly handle ClearFeature(halt)")
      Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      c503672a
  10. 17 8月, 2020 3 次提交