CVE-2026-63894: Linux Kernel Use-After-Free Vulnerability

CVE-2026-63894 Overview

CVE-2026-63894 is a use-after-free vulnerability in the Linux kernel's USB gadget FunctionFS (f_fs) subsystem. The flaw resides in the DMABUF transfer completion path, where ffs_epfile_dmabuf_io_complete() frees a usb_request structure but leaves the priv->req back-pointer dangling. A subsequent FUNCTIONFS_DMABUF_DETACH ioctl or close path call to ffs_epfile_release() then passes the freed pointer to usb_ep_dequeue().

Critical Impact
Local privileged gadget daemons can trigger memory corruption in kernel space through the FunctionFS device node, potentially leading to code execution or system compromise.

Affected Products

Linux kernel versions with USB gadget FunctionFS DMABUF support
Systems using in-tree UDCs such as chipidea and cdnsp that dereference the request in ep_dequeue()
Deployments running privileged gadget daemons (adbd, UMS, composite gadget services)

Discovery Timeline

2026-07-19 - CVE-2026-63894 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-63894

Vulnerability Analysis

The vulnerability is a classic use-after-free race condition in the FunctionFS DMABUF handling path [CWE-416]. When a DMABUF I/O completes, ffs_epfile_dmabuf_io_complete() invokes usb_ep_free_request() on the completed request. However, the priv->req back-pointer set by ffs_dmabuf_transfer() during submission continues to reference the freed memory.

A subsequent FUNCTIONFS_DMABUF_DETACH ioctl or an ffs_epfile_release() call on the file close path observes priv->req as non-NULL under ffs->eps_lock and proceeds to call usb_ep_dequeue(priv->ep, priv->req) on the freed pointer.

Behavior depends on the underlying USB Device Controller. On dummy_hcd, the dequeue path only walks a live queue and performs pointer comparisons, so the stale read does not fault directly. On SG-capable in-tree UDCs, the impact is more severe. The chipideaep_dequeue() dereferences the request via container_of() and reads hwreq->req.status before locking. The cdnsp_gadget_ep_dequeue() also reads request->status first, immediately touching freed memory.

Root Cause

The root cause is inadequate serialization between the completion callback and the cancel paths. The completion callback runs without eps_lock held, allowing cancel paths that hold eps_lock to observe a stale non-NULL priv->req while a concurrent completion frees the request. Even a narrow cmpxchg() fix in the completion cannot close the race because the two paths use different synchronization.

Attack Vector

The vulnerability is reachable only from the FunctionFS device node, which is typically owned by a privileged gadget daemon such as adbd or composite gadget services. It is not reachable from unprivileged userspace or from a USB host across the cable. However, FunctionFS mounts support uid=, gid=, and fmode= delegation, so the attacker may be a less-privileged service rather than root on some deployments.

The vulnerability manifests when an attacker with access to the FunctionFS device node races a DMABUF transfer completion against a FUNCTIONFS_DMABUF_DETACH ioctl or file close. Consult the Linux Kernel Commit references for full technical details.

Detection Methods for CVE-2026-63894

Indicators of Compromise

KASAN splats identifying usb_request objects allocated in dummy_alloc_request and freed in dummy_timer, faulted from ffs_epfile_release or the FUNCTIONFS_DMABUF_DETACH ioctl path
Unexpected kernel oops or panic traces originating from usb_ep_dequeue() in chipidea or cdnsp UDC drivers
Unusual crashes or memory corruption in processes interacting with /dev/functionfs device nodes

Detection Strategies

Enable KASAN (Kernel Address Sanitizer) on test and staging kernels to surface use-after-free accesses in the FunctionFS DMABUF paths
Audit which processes hold open file descriptors on FunctionFS mount points and monitor ioctl activity against those nodes
Track kernel version and patch status across the fleet to identify unpatched hosts running USB gadget stacks

Monitoring Recommendations

Collect kernel logs centrally and alert on oops, WARN, or KASAN messages referencing f_fs, ffs_dmabuf, or usb_ep_dequeue
Monitor privileged gadget daemons such as adbd for unexpected restarts or abnormal termination
Baseline normal FunctionFS ioctl traffic and flag anomalous FUNCTIONFS_DMABUF_DETACH frequency

How to Mitigate CVE-2026-63894

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the stable tree commits as soon as vendor-supplied updates are available
Inventory systems that use USB gadget FunctionFS with DMABUF, including Android-based devices and embedded Linux gadgets
Restrict access to FunctionFS mount points to trusted gadget daemons and avoid broad uid=/gid= delegation

Patch Information

The fix moves usb_ep_free_request() out of the completion callback and into ffs_dmabuf_cleanup(), the existing work handler scheduled by ffs_dmabuf_signal_done() on ffs->io_completion_wq. Cleanup clears priv->req under eps_lock before freeing, and only clears if priv->req still names the request. The priv refcount protects the containing ffs_dmabuf_priv across the cancel and cleanup paths. Patch commits are available at Linux Kernel Stable Tree c872d8a, 552dae2, c7d4211, and 2796646.

Workarounds

Disable the USB gadget FunctionFS DMABUF code path where it is not required for device functionality
Tighten permissions on FunctionFS mount points and avoid delegating write access to unprivileged services
Where feasible, unload the usb_f_fs module on systems that do not require USB gadget functionality

bash

# Verify kernel version and check for the patched commit
uname -r
zcat /proc/config.gz | grep CONFIG_USB_CONFIGFS_F_FS

# Restrict FunctionFS mount permissions (example)
mount -t functionfs -o uid=<gadget-uid>,gid=<gadget-gid>,fmode=0660 adb /dev/usb-ffs/adb