kernel/drivers/usb/gadget/function/f_fs.c, branch linux-6.9.y

usb: gadget: f_fs: Fix a race condition when processing setup packets.

2024-04-23T23:26:10Z

If the USB driver passes a pointer into the TRB buffer for creq, this buffer can be overwritten with the status response as soon as the event is queued. This can make the final check return USB_GADGET_DELAYED_STATUS when it shouldn't. Instead use the stored wLength. Fixes: 4d644abf2569 ("usb: gadget: f_fs: Only return delayed status when len is 0") Cc: stable Signed-off-by: Chris Wulff Link: https://lore.kernel.org/r/CO1PR17MB5419BD664264A558B2395E28E1112@CO1PR17MB5419.namprd17.prod.outlook.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete

2024-04-23T23:10:55Z

FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following: DWC3 Gadget FFS Application dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue() There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock. Fix this issue by moving the usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. This resolves the race condition above, as the ffs_aio_cancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffs_user_copy_work() not freeing the USB request until the AIO cancel is done referencing it. This fix depends on commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support") Cc: stable # b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/20240409014059.6740-1-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: functionfs: Wait for fences before enqueueing DMABUF

2024-04-04T13:20:30Z

Instead of bailing when fences have already been installed on the DMABUF, wait for them (with a timeout) when doing a blocking operation. This fixes the issue where userspace would submit a DMABUF with fences already installed, with the (correct) expectation that it would just work. Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface") Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20240402110951.16376-3-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman

usb: gadget: functionfs: Fix inverted DMA fence direction

2024-04-04T13:20:30Z

A "read" fence was installed when the DMABUF was to be written to, and a "write" fence was installed when the DMABUF was to be read from. Besides, dma_resv_usage_rw() should only be used when waiting for fences. Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface") Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20240402110951.16376-2-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman

usb: gadget: functionfs: Add DMABUF import interface

2024-02-17T16:00:09Z

This patch introduces three new ioctls. They all should be called on a data endpoint (ie. not ep0). They are: - FUNCTIONFS_DMABUF_ATTACH, which takes the file descriptor of a DMABUF object to attach to the endpoint. - FUNCTIONFS_DMABUF_DETACH, which takes the file descriptor of the DMABUF to detach from the endpoint. Note that closing the endpoint's file descriptor will automatically detach all attached DMABUFs. - FUNCTIONFS_DMABUF_TRANSFER, which requests a data transfer from / to the given DMABUF. Its argument is a structure that packs the DMABUF's file descriptor, the size in bytes to transfer (which should generally be set to the size of the DMABUF), and a 'flags' field which is unused for now. Before this ioctl can be used, the related DMABUF must be attached with FUNCTIONFS_DMABUF_ATTACH. These three ioctls enable the FunctionFS code to transfer data between the USB stack and a DMABUF object, which can be provided by a driver from a completely different subsystem, in a zero-copy fashion. Signed-off-by: Paul Cercueil Acked-by: Daniel Vetter Acked-by: Christian König Link: https://lore.kernel.org/r/20240130122340.54813-4-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman

usb: gadget: functionfs: Factorize wait-for-endpoint code

2024-02-17T16:00:09Z

This exact same code was duplicated in two different places. Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20240130122340.54813-3-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: expose ready state in configfs

2024-01-28T01:39:21Z

When a USB gadget is configured through configfs with 1 or more f_fs functions, then the logic setting up the gadget configuration has to wait until the user space code (typically separate applications) responsible for those functions have written their descriptors before the gadget can be activated. The f_fs instance already knows if this has been done, so expose it through a "ready" attribute in configfs for easier synchronization. Signed-off-by: Peter Korsgaard Link: https://lore.kernel.org/r/20240126203208.2482573-1-peter@korsgaard.com Signed-off-by: Greg Kroah-Hartman

Merge tag 'usb-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb

2024-01-18T19:43:55Z

Pull USB / Thunderbolt updates from Greg KH: "Here is the big set of USB and Thunderbolt changes for 6.8-rc1. Included in here are the following: - Thunderbolt subsystem and driver updates for USB 4 hardware and issues reported by real devices - xhci driver updates - dwc3 driver updates - uvc_video gadget driver updates - typec driver updates - gadget string functions cleaned up - other small changes All of these have been in the linux-next tree for a while with no reported issues" * tag 'usb-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (169 commits) usb: typec: tipd: fix use of device-specific init function usb: typec: tipd: Separate reset for TPS6598x usb: mon: Fix atomicity violation in mon_bin_vma_fault usb: gadget: uvc: Remove nested locking usb: gadget: uvc: Fix use are free during STREAMOFF usb: typec: class: fix typec_altmode_put_partner to put plugs dt-bindings: usb: dwc3: Limit num-hc-interrupters definition dt-bindings: usb: xhci: Add num-hc-interrupters definition xhci: add support to allocate several interrupters USB: core: Use device_driver directly in struct usb_driver and usb_device_driver arm64: dts: mediatek: mt8195: Add 'rx-fifo-depth' for cherry usb: xhci-mtk: fix a short packet issue of gen1 isoc-in transfer dt-bindings: usb: mtk-xhci: add a property for Gen1 isoc-in transfer issue arm64: dts: qcom: msm8996: Remove PNoC clock from MSS arm64: dts: qcom: msm8996: Remove AGGRE2 clock from SLPI arm64: dts: qcom: msm8998: Remove AGGRE2 clock from SLPI arm64: dts: qcom: msm8939: Drop RPM bus clocks arm64: dts: qcom: sdm630: Drop RPM bus clocks arm64: dts: qcom: qcs404: Drop RPM bus clocks arm64: dts: qcom: msm8996: Drop RPM bus clocks ...

usb: gadget: f_fs: fix fortify warning

2023-12-15T12:55:45Z

When compiling with gcc version 14.0.0 20231206 (experimental) and CONFIG_FORTIFY_SOURCE=y, I've noticed the following warning: ... In function 'fortify_memcpy_chk', inlined from '__ffs_func_bind_do_os_desc' at drivers/usb/gadget/function/f_fs.c:2934:3: ./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field' declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 588 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This call to 'memcpy()' is interpreted as an attempt to copy both 'CompatibleID' and 'SubCompatibleID' of 'struct usb_ext_compat_desc' from an address of the first one, which causes an overread warning. Since we actually want to copy both of them at once, use the convenient 'struct_group()' and 'sizeof_field()' here. Signed-off-by: Dmitry Antipov Link: https://lore.kernel.org/r/20231214090428.27292-1-dmantipov@yandex.ru Signed-off-by: Greg Kroah-Hartman

eventfd: simplify eventfd_signal()

2023-11-28T13:08:38Z

Ever since the eventfd type was introduced back in 2007 in commit e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal() function only ever passed 1 as a value for @n. There's no point in keeping that additional argument. Link: https://lore.kernel.org/r/20231122-vfs-eventfd-signal-v2-2-bd549b14ce0c@kernel.org Acked-by: Xu Yilun Acked-by: Andrew Donnellan # ocxl Acked-by: Eric Farman # s390 Reviewed-by: Jan Kara Reviewed-by: Jens Axboe Signed-off-by: Christian Brauner