# CVE-2026-63895: usb: gadget: f_fs: copy only received bytes on short ep0 read

> A privileged local attacker can read uninitialized kernel memory via a short USB control transfer in the Linux kernel's FunctionFS driver.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** An administrator
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 19 Jul 2026
- **Updated:** 19 Jul 2026
- **Also known as:** BELL-CVE-2026-63895, DEBIAN-CVE-2026-63895, GHSA-hqp4-gw43-6pcc, ROOT-OS-DEBIAN-11-CVE-2026-63895, ROOT-OS-UBUNTU-2204-CVE-2026-63895, UBUNTU-CVE-2026-63895

## What is CVE-2026-63895?

CVE-2026-63895 is a vulnerability in Linux, published on 19 Jul 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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.

## Which versions are affected by CVE-2026-63895?


## How do I fix CVE-2026-63895?

Apply the vendor's patch.

## Is CVE-2026-63895 being exploited?

There is no known exploitation of CVE-2026-63895 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-63895 and fix it if it is affected.

What it is: CVE-2026-63895 is a vulnerability in Linux, published on 19 Jul 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-63895 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-63895/ (Markdown: https://insights.sbomify.com/CVE-2026-63895/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-63895
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-63895
- OSV: https://osv.dev/vulnerability/CVE-2026-63895

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-63895/
Summaries are generated and may contain mistakes; the official description above is the record.