CVE-2026-93121: usb: gadget: f_fs: Fix fence cleanup in ffs_dmabuf_transfer() error paths
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ffs: Fix fence cleanup in ffsdmabuftransfer() error paths
The error paths for endpoint-disabled (ESHUTDOWN) and request-allocation failure (ENOMEM) in ffsdmabuftransfer() jump to errfenceput which calls dmafenceput() on the fence. However, at that point the fence has only been kmalloc'd — dmafenceinit() has not been called yet, so the refcount and the fence ops are uninitialized. Calling dmafenceput() on such an object leads to undefined behavior.
Use kfree() instead, since the fence is just a plain allocation at this stage, and rename the label to errfencefree to reflect the actual cleanup action.
Event History
Frequently Asked Questions
Under what conditions can the faulty cleanup path be reached?
It can be reached when ffs_dmabuf_transfer() encounters an endpoint-disabled error (ESHUTDOWN) or cannot allocate a request (ENOMEM), after the fence memory has been allocated but before dma_fence_init() is called.
What is the impact of reaching the affected error paths?
The kernel calls dma_fence_put() on an uninitialized fence object. Because its reference count and fence operations are uninitialized, this results in undefined behavior.
Is there a documented workaround if the fix cannot be deployed immediately?
No workaround is provided in the available information. The documented correction is to free the not-yet-initialized fence allocation with kfree() rather than calling dma_fence_put().