CVE-2026-64328

What it actually does

This is a Linux kernel memory leak in the USB gadget FunctionFS DMA-buf transfer path. During ffs_dmabuf_transfer(), a ffs_dma_fence object is allocated and its embedded dma_fence receives an initial reference. A second reference is taken when the fence is added to the DMA reservation object, but the original reference is not released. Repeated DMA-buf transfers through the vulnerable USB gadget FunctionFS path can therefore leave ffs_dma_fence objects permanently allocated, gradually consuming kernel memory. The practical technical impact is local or device-adjacent denial of service through memory exhaustion, depending on whether an attacker can cause repeated FunctionFS DMA-buf USB gadget transfers on the affected system.

Why it matters to the business

Systems using affected Linux kernels with USB gadget FunctionFS and DMA-buf functionality exposed can suffer progressive memory exhaustion, instability, degraded device behavior, or crashes. This is most relevant to embedded devices, Android-derived systems, appliances, development boards, kiosks, or products that operate in USB peripheral/gadget mode. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported exploit maturity, so broad opportunistic exploitation is unlikely; however, organizations shipping or operating Linux-based devices with USB gadget capabilities should still treat it as a reliability and availability fix.

How an attack unfolds

An attacker must be able to interact with or trigger the vulnerable USB gadget FunctionFS DMA-buf transfer functionality. They repeatedly cause transfers that allocate ffs_dma_fence objects. Each transfer adds the fence to a DMA reservation object but leaves the original reference outstanding, preventing the object from being freed after completion. Over time, unreclaimed kernel allocations accumulate. If the attacker can sustain enough transfer activity, available kernel memory is depleted, leading to performance degradation, allocation failures, service disruption, or a system crash/reboot. There is no indication from the provided data that this enables code execution or privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the USB gadget FunctionFS DMA fence reference leak. The fix releases the initial fence reference after dma_resv_add_fence() by calling dma_fence_put(), transferring ownership correctly to the DMA reservation object. If a vendor kernel is used, apply the corresponding vendor security or stable kernel update when available. If immediate patching is not possible, reduce exposure by disabling unused USB gadget/FunctionFS functionality, disabling DMA-buf paths where feasible, restricting physical or logical access to USB gadget interfaces, and monitoring affected devices for abnormal kernel memory growth or repeated USB gadget transfer activity.

How to confirm the fix worked

Confirm that the running kernel includes the patch changing ffs_dmabuf_transfer() ownership handling so that dma_fence_put() is called after dma_resv_add_fence(). Validate through vendor advisories, kernel package changelogs, source inspection, or by comparing against the fixed upstream commit in the relevant stable branch. On systems where FunctionFS DMA-buf is used, perform regression testing with repeated gadget transfers and verify that kernel memory usage/slab allocations do not grow unbounded after transfer completion. Also confirm that any mitigation, such as disabling USB gadget FunctionFS, is active after reboot and reflected in the running kernel configuration or loaded modules.

Typical attack path

1. Identify a Linux-based target that runs an affected kernel and exposes USB gadget FunctionFS with DMA-buf transfer support.
2. Gain the ability to interact with the gadget interface or otherwise trigger FunctionFS DMA-buf transfers.
3. Repeatedly initiate transfers that cause ffs_dmabuf_transfer() to allocate ffs_dma_fence objects.
4. Allow the leaked fence references to accumulate in kernel memory over many operations.
5. Continue the activity until the device experiences memory pressure, kernel allocation failures, degraded functionality, or denial of service.

How to detect it

Look for evidence of exploitation or stress by reviewing kernel logs, system journals, device telemetry, and crash records for memory pressure occurring alongside USB gadget FunctionFS activity. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, Android or embedded device kernel logs, watchdog reset logs, and crash dumps. Indicators are likely behavioral rather than a unique exploit signature: repeated USB gadget or FunctionFS transfer activity, steadily increasing kernel memory or slab usage, out-of-memory killer events, allocation failures, hung tasks, watchdog resets, or device reboots. If available, compare time series for USB gadget traffic or FunctionFS operations against memory consumption. Forensic confirmation may require kernel memory/slab analysis showing growth in DMA fence-related allocations after repeated FunctionFS DMA-buf activity.

• ffs_dmabuf_transfer
• ffs_dmabuf_cleanup
• ffs_dmabuf_signal_done
• FunctionFS
• functionfs
• usb: gadget
• usb gadget
• g_ffs
• dma_fence
• dma_resv_add_fence
• DMA fence
• Out of memory
• oom-killer
• Memory allocation failure
• page allocation failure
• kernel panic - not syncing
• watchdog: BUG: soft lockup
• hung task
• /dev/usb-ffs
• /sys/kernel/config/usb_gadget

What your security team should do

• Inventory Linux-based devices and products that use USB gadget mode, FunctionFS, or DMA-buf transfer functionality, especially embedded, mobile, appliance, and peripheral-mode systems.
• Prioritize patching affected kernels on devices where untrusted users, hosts, or physical operators can trigger USB gadget transfers.
• Track vendor kernel advisories and stable kernel updates because fixed versions were not provided in the input.
• If patching is delayed, disable unused USB gadget and FunctionFS features or restrict access to interfaces that can trigger DMA-buf transfers.
• Monitor affected systems for gradual kernel memory growth, out-of-memory events, USB gadget errors, or unexplained reboots.
• Because the vulnerability is not in KEV, has low EPSS, and has no known public exploit maturity, prioritize based on exposure and device criticality rather than treating it as an internet-scale emergency.