CVE-2026-64328: usb: gadget: f_fs: Fix DMA fence leak
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ffs: Fix DMA fence leak
In ffsdmabuftransfer(), a ffsdmafence object is kmalloc'd, with the underlying dmafence later initialized by dmafenceinit(), which sets its kref counter to 1. Then, dmaresvaddfence() gets a second reference, and a pointer to the ffsdmafence is passed as the usbrequest's "context" field.
The dma-resv mechanism will manage the second reference, but the first reference is never properly released; the ffsdmabufcleanup() function decreases the reference count, but only to balance with the reference grab in ffsdmabufsignaldone().
The code will then slowly leak memory as more ffsdmafence objects are created without being ever freed.
Address this issue by transferring ownership of the fence to the DMA reservation object, by calling dmafenceput() right after dmaresvaddfence(). The ffsdmafence then gets properly discarded after being signalled.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Update the Linux kernel using the provided fix: "usb: gadget: f_fs: Fix DMA fence leak" (transfer ownership of the fence to the DMA so the ffs_dma_fence reference is released correctly, avoiding the memory leak).
Event History
Frequently Asked Questions
What level of access is required to trigger this issue?
The CVSS vector indicates local access with low privileges is required. No user interaction is needed.
What is the likely operational impact?
Repeated DMA-buffer transfers can slowly leak ffs_dma_fence objects. The issue is rated as having high availability impact, so sustained use may degrade system availability.
Which code path is involved?
The leak occurs when ffs_dmabuf_transfer() creates an ffs_dma_fence and adds it to a DMA reservation object without releasing the original fence reference.