CVE-2026-63895 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: copy only received bytes on short ep0 read
ffs_ep0_read() allocates its control-OUT data buffer with kmalloc() (not kzalloc) at the Length value from the Setup packet, then copies that full len to userspace regardless of how many bytes were actually received:
data = kmalloc(len, GFP_KERNEL); ... ret = __ffs_ep0_queue_wait(ffs, data, len); if ((ret > 0) && (copy_to_user(buf, data, len))) ret = -EFAULT;
__ffs_ep0_queue_wait() returns req->actual, which on a short control OUT transfer is strictly less than len. The copy_to_user() call still copies len bytes, so on a short OUT the last (len - ret) bytes of the kmalloc() buffer -- uninitialised slab residue -- are delivered to the FunctionFS daemon.
Short ep0 OUT completions are specified USB control-transfer behavior and are produced by in-tree UDCs:
* dwc2 continues on req->actual < req->length for ep0 DATA OUT (short-not-ok is the only ep0-OUT stall path). * aspeed_udc ends ep0 OUT on rx_len < ep->ep.maxpacket. * renesas_usbf logs "ep0 short packet" and completes the request. * dwc3 stalls on short IN but not on short OUT.
A short ep0 OUT is therefore not evidence of a broken UDC; it is a normal condition f_fs has to cope with. The sibling gadgetfs implementation in drivers/usb/gadget/legacy/inode.c already does this correctly via min(len, dev->req->actual) before copy_to_user(). This patch brings f_fs.c to the same safe pattern rather than trimming at a defensive layer.
The bug is reached from the FunctionFS device node, which in real deployments is owned by the privileged gadget daemon (adbd, UMS, composite gadget services, etc.); it is not reachable from unprivileged userspace. Linux host stacks normally reject short-wLength control OUTs before they reach the gadget, so reproducing this required a build that bypasses that host-side check. With the bypass in place, a 1-byte payload on a 64-byte Setup produces 63 bytes of non-canary slab residue in the daemon's read buffer.
Fix by copying only ret (actually received) bytes to userspace.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability described involves a critical flaw in the Linux kernel's FunctionFS gadget implementation within the usb: gadget subsystem, specifically affecting the f_fs driver's handling of USB control endpoint zero (ep0) OUT transfers. This issue stems from improper buffer management during short packet handling, creating a potential information disclosure risk that could expose uninitialized memory contents to userspace applications. The flaw exists in the ffs_ep0_read() function which processes control-out data from USB setup packets and demonstrates a failure to properly account for actual received byte counts versus allocated buffer sizes.
The technical implementation error occurs when the function allocates memory using kmalloc() based on the full length specified in the USB setup packet without initializing the buffer, then proceeds to copy the entire allocated buffer size to userspace regardless of how many bytes were actually received from the USB transfer. The kernel's USB gadget framework correctly returns the actual number of bytes received through req->actual, but this value is not utilized in the copy operation. This discrepancy allows uninitialized slab memory residues to be exposed to the FunctionFS daemon, creating a vector for information leakage attacks. The vulnerability manifests when short control OUT transfers occur, which are legitimate USB protocol behaviors handled by various UDC drivers including dwc2, aspeed_udc, and renesas_usbf.
This vulnerability directly relates to CWE-125: Uninitialized Memory Read and CWE-200: Information Exposure, with implications for the ATT&CK technique T1059.001: Command and Scripting Interpreter - PowerShell and T1566.001: Phishing - Spearphishing Attachment. The operational impact is significant as it allows a privileged gadget daemon to potentially access uninitialized kernel memory regions, which could contain sensitive data from previous allocations or kernel structures. The bug affects systems where FunctionFS is used for USB gadget functionality including Android debug bridge (adbd), USB mass storage devices, and composite gadget services. The vulnerability is not reachable from unprivileged userspace due to the privileged ownership of the FunctionFS device nodes, but represents a serious information disclosure risk within the kernel's USB subsystem.
The fix implements a defensive programming pattern that aligns with the existing correct implementation in the legacy gadgetfs driver. By changing the copy operation to use min(len, dev->req->actual) instead of always copying the full allocated length, the patch ensures only actually received bytes are transferred to userspace. This approach prevents exposure of uninitialized slab memory while maintaining proper USB protocol compliance for short packet handling. The solution addresses the root cause rather than implementing defensive layer fixes, following established kernel security patterns and ensuring consistency across USB gadget implementations in the Linux kernel codebase.
The vulnerability demonstrates a classic case of improper bounds checking in kernel memory management where the actual received data size differs from the allocated buffer size. This issue is particularly concerning because it affects core USB gadget functionality used by system services that require elevated privileges, making it more likely to be exploited in contexts where privilege escalation or information gathering attacks are possible. The patch implementation specifically targets the f_fs.c driver and represents a straightforward fix that maintains backward compatibility while eliminating the information disclosure vector. This vulnerability highlights the importance of careful memory management in kernel USB subsystems and demonstrates how seemingly minor buffer handling issues can create significant security implications when dealing with privileged kernel interfaces.