CVE-2026-63895

What it actually does

This is an information disclosure flaw in the Linux kernel USB FunctionFS gadget implementation. When a privileged FunctionFS daemon reads control endpoint 0 data, the kernel allocates a buffer sized from the USB setup packet length, but on a short control-OUT transfer it may receive fewer bytes than requested. Vulnerable kernels copy the full requested length back to userspace instead of only the bytes actually received, exposing uninitialized kernel heap/slab residue to the gadget daemon. The flaw does not provide direct code execution or direct unprivileged local access; exploitation requires a system acting as a USB gadget using FunctionFS and a USB host capable of sending a short control-OUT transfer that reaches the gadget.

Why it matters to the business

The main risk is leakage of kernel memory contents on devices that expose USB gadget functionality, such as embedded Linux systems, Android-style debug/ADB gadgets, USB mass-storage/composite gadgets, or appliance management ports. The leaked data is small per request but may contain sensitive kernel-resident residue, pointers, or data fragments that could help an attacker defeat hardening or support follow-on exploitation. The vulnerability is not in CISA KEV, is not reported as ransomware-used, has low EPSS, and has no known public exploit maturity, so urgency is highest for products with exposed USB device-mode ports or untrusted physical/host connectivity.

How an attack unfolds

An attacker positions a malicious or specially modified USB host so it can communicate with a Linux device operating in USB gadget mode with FunctionFS enabled. The host sends a control-OUT setup packet with a declared length larger than the payload it actually transmits. If the short transfer is accepted by the USB device controller and delivered to FunctionFS, the kernel receives fewer bytes than the requested length but copies the entire requested buffer to the privileged FunctionFS daemon. The tail of that buffer contains stale, uninitialized slab memory. The attacker can then obtain the leaked bytes if the daemon logs, processes, reflects, or otherwise exposes the read buffer, or if the attacker controls/observes the gadget protocol implemented by that daemon. Repeating the interaction may leak additional small fragments of kernel memory.

How to fix it

Apply a vendor kernel update that includes the fix for the FunctionFS endpoint 0 short-read handling, specifically the change that copies only the actual received byte count rather than the requested setup length. If maintaining a custom kernel, backport the upstream patch for `drivers/usb/gadget/function/f_fs.c` so `copy_to_user()` uses the actual return length, or an equivalent `min(requested_length, actual_length)` pattern. Where immediate patching is not possible, reduce exposure by disabling unused USB gadget functions, disabling or restricting ADB/FunctionFS-based services, limiting physical access to USB device-mode ports, allowing connections only to trusted hosts, and reviewing gadget daemons to ensure they do not log, reflect, or expose raw endpoint 0 buffers.

How to confirm the fix worked

Confirm the running kernel package or source tree contains the FunctionFS fix in `drivers/usb/gadget/function/f_fs.c`: after `__ffs_ep0_queue_wait()` returns the actual byte count, the userspace copy should be limited to that actual count rather than the original setup length. Validate configuration exposure by checking whether FunctionFS support and USB gadget services are enabled, such as `CONFIG_USB_FUNCTIONFS`, mounted FunctionFS instances, and active gadget daemons. In a controlled lab, use a USB host/test harness capable of sending a short control-OUT transfer and verify that the daemon receives only the actual payload length and no uninitialized tail bytes. Because normal Linux host stacks may reject this malformed condition before it reaches the gadget, validation may require specialized USB hardware, controller tooling, or modified host-side software.

Typical attack path

1. Identify a target device that runs Linux in USB gadget/device mode and uses FunctionFS, such as ADB, composite gadget, or a custom USB gadget service.
2. Connect the target to an attacker-controlled USB host or test rig capable of bypassing normal host-side checks for short control-OUT transfers.
3. Send a control-OUT setup packet on endpoint 0 with a declared wLength larger than the actual data payload sent.
4. Trigger the FunctionFS daemon to read from endpoint 0 so the vulnerable kernel path copies the requested length rather than the actual received length.
5. Collect or infer the leaked uninitialized bytes from the daemon’s protocol behavior, logs, responses, or downstream handling.
6. Repeat the short-transfer sequence to gather additional kernel heap residue and use any useful values for reconnaissance or follow-on exploitation.

How to detect it

Retrospective detection is difficult because the bug leaks memory through normal FunctionFS read behavior and may not produce a clear kernel error. Review telemetry from devices that operate as USB gadgets, including kernel logs, USB controller driver logs, FunctionFS or gadget daemon logs, audit records for reads from FunctionFS endpoint files, usbmon captures, ftrace/perf USB gadget events, and physical access records for USB connections. Hunt for repeated or unusual endpoint 0 control-OUT activity where the setup packet length exceeds the actual payload, short-packet messages from USB device controller drivers, resets/re-enumerations around gadget services, or daemon logs containing unexpected binary data after control requests. If available, correlate suspicious USB activity with processes such as ADB or custom gadget daemons reading FunctionFS endpoint 0. Absence of logs does not rule out exploitation; many production systems do not retain the low-level USB traces needed to prove or disprove this condition.

• ep0 short packet
• short ep0 OUT
• req->actual < req->length
• /dev/usb-ffs/
• /dev/usb-ffs/*/ep0
• /sys/kernel/config/usb_gadget/
• FunctionFS
• ffs_ep0_read
• adbd

What your security team should do

• Prioritize patching devices and products that expose USB gadget/device-mode ports to untrusted users, field technicians, public kiosks, vehicles, labs, or supply-chain handling environments.
• Inventory Linux-based products and images for FunctionFS usage, including ADB, custom composite gadgets, and services mounted under FunctionFS paths.
• Update to vendor kernels containing the FunctionFS short ep0 read fix, or backport the `f_fs.c` change into maintained product kernels.
• If patching is delayed, disable unused gadget functions and restrict physical access or host connectivity to device-mode USB ports.
• Review gadget daemon behavior to ensure endpoint 0 input buffers are not logged, returned to a host, or incorporated into externally visible protocol responses without length validation.
• Add detection coverage for unusual USB control-OUT short-packet activity and repeated endpoint 0 errors on exposed gadget devices, recognizing that many environments will have limited USB telemetry.
• Treat evidence of repeated crafted short control transfers as suspicious even though there are no known public exploitation campaigns, KEV listing, or ransomware association.