CVE-2026-64328: Linux Kernel USB Gadget Memory Leak Flaw

CVE-2026-64328 Overview

CVE-2026-64328 is a memory leak vulnerability in the Linux kernel's USB gadget FunctionFS (f_fs) subsystem. The flaw resides in the ffs_dmabuf_transfer() function, where a ffs_dma_fence object is allocated with kmalloc() and initialized through dma_fence_init(). The reference counting logic fails to release the initial fence reference, causing memory to leak with every DMA-buffer transfer operation. Over time, repeated allocations exhaust kernel memory on affected systems that use USB gadget DMA-buffer transfers.

Critical Impact
Progressive kernel memory exhaustion on Linux systems using USB gadget FunctionFS DMA-buffer transfers, potentially leading to denial of service.

Affected Products

Linux kernel versions containing the f_fs DMA-buffer transfer implementation prior to the fix commits
Linux stable branches referenced by commits 0cae3d6, b7475b2, baa6b60, and e086c16
Systems using USB gadget FunctionFS with DMA-buffer transfer support enabled

Discovery Timeline

2026-07-25 - CVE-2026-64328 published to NVD
2026-07-25 - Last updated in NVD database

Technical Details for CVE-2026-64328

Vulnerability Analysis

The vulnerability exists in the Linux kernel USB gadget FunctionFS (f_fs) driver, specifically in the DMA-buffer transfer path. When ffs_dmabuf_transfer() is invoked, the driver allocates a ffs_dma_fence structure using kmalloc(). It then calls dma_fence_init(), which sets the fence's kref reference counter to 1. Subsequently, dma_resv_add_fence() acquires a second reference on the fence, and a pointer to the ffs_dma_fence is stored in the usb_request context field.

The DMA reservation subsystem correctly manages its acquired reference. However, the original reference from dma_fence_init() is never released. The ffs_dmabuf_cleanup() function only decrements the reference count to balance the grab performed in ffs_dmabuf_signal_done(). Each transfer operation therefore leaks one ffs_dma_fence allocation, gradually consuming kernel memory.

Root Cause

The root cause is improper reference count ownership handling between the caller and the DMA reservation object. The code assumes the second reference obtained by dma_resv_add_fence() supersedes the initial reference from dma_fence_init(), when in fact both references must be explicitly released. This is a memory leak classification, driven by reference counting logic that does not transfer ownership of the fence to the reservation object.

Attack Vector

The issue is triggered through local operations that invoke DMA-buffer transfers via the USB gadget FunctionFS interface. Any workload that repeatedly performs ffs_dmabuf_transfer() calls will accumulate leaked ffs_dma_fence objects. The vulnerability does not enable code execution or privilege escalation, but sustained exploitation leads to kernel memory exhaustion and eventual denial of service on the affected host.

The upstream fix transfers ownership of the fence to the DMA reservation object by invoking dma_fence_put() immediately after dma_resv_add_fence(). The ffs_dma_fence is then properly discarded once it is signalled. See the kernel commits 0cae3d6, b7475b2, baa6b60, and e086c16 for the full patch context.

Detection Methods for CVE-2026-64328

Indicators of Compromise

Steadily increasing kernel slab allocations associated with kmalloc-* caches on hosts that use USB gadget FunctionFS
Growth in unaccounted kernel memory reported by /proc/meminfoSlab and SUnreclaim counters without corresponding userspace pressure
Long-running systems using USB gadget DMA-buffer transfers exhibiting out-of-memory events without an obvious userspace culprit

Detection Strategies

Compare the running kernel version against the fixed commits published on git.kernel.org and identify hosts still running vulnerable revisions
Instrument affected hosts with kmemleak or eBPF-based allocation tracking to observe unreleased ffs_dma_fence allocations
Track USB gadget FunctionFS usage patterns and correlate transfer volume with kernel memory growth on the same host

Monitoring Recommendations

Alert on sustained Slab growth in kernel memory metrics on Linux endpoints running USB gadget FunctionFS workloads
Monitor dmesg output for OOM killer activations tied to kernel allocations rather than user processes
Track kernel version inventory across managed Linux fleets to confirm patch coverage against CVE-2026-64328

How to Mitigate CVE-2026-64328

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in commits 0cae3d6, b7475b2, baa6b60, and e086c16 on affected stable branches
Prioritize patching on hosts that actively use USB gadget FunctionFS DMA-buffer transfers, such as embedded devices and development boards
Reboot patched systems to load the fixed kernel image and clear any leaked memory accumulated by the vulnerable build

Patch Information

The fix has been merged into Linux kernel stable branches. The patch modifies ffs_dmabuf_transfer() to call dma_fence_put() immediately after dma_resv_add_fence(), transferring ownership of the initial reference to the DMA reservation object. Distribution vendors are expected to backport the change; consult your distribution's security tracker for the kernel package that includes the fix. Reference commits are available at 0cae3d6, b7475b2, baa6b60, and e086c16.

Workarounds

Disable USB gadget FunctionFS DMA-buffer transfer functionality on systems where it is not required until the kernel patch is applied
Schedule periodic reboots of long-running systems that cannot be patched immediately to reclaim leaked kernel memory
Restrict local access to the FunctionFS interface to trusted processes to reduce the rate of leak accumulation

bash

# Verify running kernel version and confirm patch presence
uname -r

# Inspect kernel slab usage growth over time on affected hosts
watch -n 60 'grep -E "^Slab|^SUnreclaim" /proc/meminfo'

# Enable kmemleak (requires CONFIG_DEBUG_KMEMLEAK) and scan for leaks
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak