Bug 2507246 (CVE-2026-64328)

Summary: CVE-2026-64328 kernel: usb: gadget: f_fs: Fix DMA fence leak
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's USB gadget subsystem. Specifically, a DMA (Direct Memory Access) fence leak exists in the `f_fs` module's `ffs_dmabuf_transfer()` function. This issue causes `ffs_dma_fence` objects to be allocated without their initial reference being properly released. Repeated exploitation of this flaw could lead to a gradual memory leak, potentially resulting in a denial of service due to system resource exhaustion.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-07-25 10:12:39 UTC 
In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Fix DMA fence leak

In ffs_dmabuf_transfer(), a ffs_dma_fence object is kmalloc'd, with the
underlying dma_fence later initialized by dma_fence_init(), which sets
its kref counter to 1. Then, dma_resv_add_fence() gets a second
reference, and a pointer to the ffs_dma_fence is passed as the
usb_request's "context" field.

The dma-resv mechanism will manage the second reference, but the first
reference is never properly released; the ffs_dmabuf_cleanup() function
decreases the reference count, but only to balance with the reference
grab in ffs_dmabuf_signal_done().

The code will then slowly leak memory as more ffs_dma_fence objects are
created without being ever freed.

Address this issue by transferring ownership of the fence to the DMA
reservation object, by calling dma_fence_put() right after
dma_resv_add_fence(). The ffs_dma_fence then gets properly discarded
after being signalled.
Comment 1 TEJ RATHI 2026-07-29 07:50:32 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026072513-CVE-2026-64328-f1c7@gregkh/T