kernel/linux.git/drivers/usb/gadget/function/f_fs.c, branch v6.19.12

usb: gadget: f_fs: Fix ioctl error handling

2026-03-04T12:20:41+00:00

[ Upstream commit 8e4c1d06183c25022f6b0002a5cab84979ca6337 ] When ffs_epfile_ioctl handles FUNCTIONFS_DMABUF_* ioctls, it's currently falling through when copy_from_user fails. However, this fallthrough isn't being checked properly, so the handler continues executing further than it should. It then tries the secondary dispatch where it ultimately gives up and returns -ENOTTY. The end result is invalid ioctl invocations will yield a -ENOTTY rather than an -EFAULT. It's a common pattern elsewhere in the kernel code to directly return -EFAULT when copy_from_user fails. So we update ffs_epfile_ioctl to do the same and fix this issue. Signed-off-by: Sam Day Link: https://patch.msgid.link/20260108-ffs-dmabuf-ioctl-fix-v1-1-e51633891a81@samcday.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: gadget: f_fs: fix DMA-BUF OUT queues

2026-03-04T12:20:41+00:00

[ Upstream commit 0145e7acd29855dfba4a2f387d455b5d9a520f0e ] Currently, DMA_FROM_DEVICE is used when attaching DMABUFs to IN endpoints and DMA_TO_DEVICE for OUT endpoints. This is inverted from how it should be. The result is IOMMU read-only mappings placed on OUT queues, triggering arm-smmu write faults. Put differently, OUT endpoints flow data from host -> gadget, meaning the UDC peripheral needs to have write access to the buffer to fill it with the incoming data. This commit flips the directions and updates the implicit-sync helpers so IN endpoints act as readers and OUT endpoints as writers. Signed-off-by: Sam Day Tested-by: David Heidelberg # OnePlus 6T on sdm845-next-20251119 Link: https://patch.msgid.link/20260108-ffs-dmabuf-ioctl-fix-v1-2-e51633891a81@samcday.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

functionfs: use spinlock for FFS_DEACTIVATED/FFS_CLOSING transitions

2026-02-05T18:53:12+00:00

When all files are closed, functionfs needs ffs_data_reset() to be done before any further opens are allowed. During that time we have ffs->state set to FFS_CLOSING; that makes ->open() fail with -EBUSY. Once ffs_data_reset() is done, it switches state (to FFS_READ_DESCRIPTORS) indicating that opening that thing is allowed again. There's a couple of additional twists: * mounting with -o no_disconnect delays ffs_data_reset() from doing that at the final ->release() to the first subsequent open(). That's indicated by ffs->state set to FFS_DEACTIVATED; if open() sees that, it immediately switches to FFS_CLOSING and proceeds with doing ffs_data_reset() before returning to userland. * a couple of usb callbacks need to force the delayed transition; unfortunately, they are done in locking environment that does not allow blocking and ffs_data_reset() can block. As the result, if these callbacks see FFS_DEACTIVATED, they change state to FFS_CLOSING and use schedule_work() to get ffs_data_reset() executed asynchronously. Unfortunately, the locking is rather insufficient. A fix attempted in e5bf5ee26663 ("functionfs: fix the open/removal races") had closed a bunch of UAF, but it didn't do anything to the callbacks, lacked barriers in transition from FFS_CLOSING to FFS_READ_DESCRIPTORS _and_ it had been too heavy-handed in open()/open() serialization - I've used ffs->mutex for that, and it's being held over actual IO on ep0, complete with copy_from_user(), etc. Even more unfortunately, the userland side is apparently racy enough to have the resulting timing changes (no failures, just a delayed return of open(2)) disrupt the things quite badly. Userland bugs or not, it's a clear regression that needs to be dealt with. Solution is to use a spinlock for serializing these state checks and transitions - unlike ffs->mutex it can be taken in these callbacks and it doesn't disrupt the timings in open(). We could introduce a new spinlock, but it's easier to use the one that is already there (ffs->eps_lock) instead - the locking environment is safe for it in all affected places. Since now it is held over all places that alter or check the open count (ffs->opened), there's no need to keep that atomic_t - int would serve just fine and it's simpler that way. Fixes: e5bf5ee26663 ("functionfs: fix the open/removal races") Fixes: 18d6b32fca38 ("usb: gadget: f_fs: add "no_disconnect" mode") # v4.0 Tested-by: Samuel Wu Signed-off-by: Al Viro

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

2025-12-07T02:42:12+00:00

Pull USB/Thunderbolt updates from Greg KH: "Here is the big set of USB and Thunderbolt driver updates for 6.19-rc1. Nothing major here, just lots of tiny updates for most of the common USB drivers. Included in here are: - more xhci driver updates and fixes - Thunderbolt driver cleanups - usb serial driver updates - typec driver updates - USB tracepoint additions - dwc3 driver updates, including support for Apple hardware - lots of other smaller driver updates and cleanups All of these have been in linux-next for a while with no reported issues" * tag 'usb-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (161 commits) usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt USB: serial: option: move Telit 0x10c7 composition in the right place USB: serial: option: add Telit Cinterion FE910C04 new compositions usb: typec: ucsi: fix use-after-free caused by uec->work usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe() usb: dwc3: core: Remove redundant comment in core init usb: phy: Initialize struct usb_phy list_head USB: serial: option: add Foxconn T99W760 usb: usb-storage: No additional quirks need to be added to the EL-R12 optical drive. usb: typec: hd3ss3220: Enable VBUS based on ID pin state dt-bindings: usb: ti,hd3ss3220: Add support for VBUS based on ID state usb: typec: anx7411: add WQ_PERCPU to alloc_workqueue users USB: add WQ_PERCPU to alloc_workqueue users dt-bindings: usb: dwc3-xilinx: Describe the reset constraint for the versal platform drivers/usb/storage: use min() instead of min_t() usb: raw-gadget: cap raw_io transfer length to KMALLOC_MAX_SIZE usb: ohci-da8xx: remove unused platform data usb: gadget: functionfs: use dma_buf_unmap_attachment_unlocked() helper usb: uas: reduce time under spinlock usb: dwc3: eic7700: Add EIC7700 USB driver ...

usb: gadget: functionfs: use dma_buf_unmap_attachment_unlocked() helper

2025-11-21T14:13:52+00:00

Replace the open-coded dma_resv_lock()/dma_resv_unlock() around dma_buf_unmap_attachment() in ffs_dmabuf_release() with the dma_buf_unmap_attachment_unlocked() helper. This aligns FunctionFS DMABUF unmap handling with the standard DMA-BUF API, avoids duplicating locking logic and eases future maintenance. No functional change. Reviewed-by: fanggeng Signed-off-by: Liang Jie Link: https://patch.msgid.link/20251114084246.2064845-1-buaajxlj@163.com Signed-off-by: Greg Kroah-Hartman

convert functionfs

2025-11-18T04:59:05+00:00

All files are regular; ep0 is there all along, other ep* may appear and go away during the filesystem lifetime; all of those are guaranteed to be gone by the time we umount it. Object creation is in ffs_sb_create_file(), removals - at ->kill_sb() time (for ep0) or by simple_remove_by_name() from ffs_epfiles_destroy() (for the rest of them). Switch ffs_sb_create_file() to simple_start_creating()/d_make_persistent()/ simple_done_creating() and that's it. Signed-off-by: Al Viro

functionfs: switch to simple_remove_by_name()

2025-11-18T04:57:39+00:00

No need to return dentry from ffs_sb_create_file() or keep it around afterwards. To avoid subtle issues with getting to ffs from epfiles in ffs_epfiles_destroy(), pass the superblock as explicit argument. Callers have it anyway. Reviewed-by: Greg Kroah-Hartman Signed-off-by: Al Viro

functionfs: fix the open/removal races

2025-11-18T04:54:42+00:00

ffs_epfile_open() can race with removal, ending up with file->private_data pointing to freed object. There is a total count of opened files on functionfs (both ep0 and dynamic ones) and when it hits zero, dynamic files get removed. Unfortunately, that removal can happen while another thread is in ffs_epfile_open(), but has not incremented the count yet. In that case open will succeed, leaving us with UAF on any subsequent read() or write(). The root cause is that ffs->opened is misused; atomic_dec_and_test() vs. atomic_add_return() is not a good idea, when object remains visible all along. To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we had zero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from the callback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed, along with checking that state is FFS_ACTIVE. Reviewed-by: Greg Kroah-Hartman Signed-off-by: Al Viro

functionfs: need to cancel ->reset_work in ->kill_sb()

2025-11-18T04:53:51+00:00

... otherwise we just might free ffs with ffs->reset_work still on queue. That needs to be done after ffs_data_reset() - that's the cutoff point for configfs accesses (serialized on gadget_info->lock), which is where the schedule_work() would come from. Reviewed-by: Greg Kroah-Hartman Signed-off-by: Al Viro

functionfs: don't bother with ffs->ref in ffs_data_{opened,closed}()

2025-11-18T04:52:57+00:00

A reference is held by the superblock (it's dropped in ffs_kill_sb()) and filesystem will not get to ->kill_sb() while there are any opened files, TYVM... Reviewed-by: Greg Kroah-Hartman Signed-off-by: Al Viro