In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Fix Use-After-Free in AIO error path
In ffs_epfile_write_iter() and ffs_epfile_read_iter(), when ffs_epfile_io()
fails with an error other than -EIOCBQUEUED, the io_data structure (p) is
freed. However, for AIO operations, the kiocb cancel function was already
armed and kiocb->private was set to p.
If a concurrent cancel operation (such as sys_io_cancel()) executes after
ffs_epfile_io() fails but before the function frees p, a Use-After-Free
can occur when the cancellation handler accesses the freed pointer.
To securely fix this race condition, we must properly un-arm the
cancellation. Invoking kiocb->ki_complete() does exactly this by
acquiring ctx->ctx_lock and safely removing the kiocb from the active
sequence. In doing so, it ensures that a parallel io_cancel can no longer
discover the kiocb, effectively closing the race window.
We then return -EIOCBQUEUED to notify the VFS layer that the kiocb has been
consumed and it should avoid attempting to complete the request again or
triggering subsequent completion handlers.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The UAF is in FunctionFS epfile AIO (ffs_epfile_write_iter/read_iter via io_submit/io_cancel on functionfs ep files), a local syscall path. ffs_epfile_io() can fail with -EAGAIN on O_NONBLOCK before any USB host is involved; this is the gadget userspace API, matching CVE-2024-36894/CVE-2026-63894 as Local rather than Physical.
AC:L - The attacker controls both sides: one thread io_submits AIO that fails after kiocb_set_cancel_fn (O_NONBLOCK -EAGAIN, halt, -EFAULT), while another calls io_cancel/io_destroy. The race between kfree(p) and aio_remove_iocb is freely retryable, so a race the attacker creates is AC:L.
PR:L - FunctionFS mounts commonly use uid=/gid=/fmode= to delegate ep files to unprivileged gadget daemons (adbd/shell on Android, MTP, embedded USB services). Once mounted by init, those accounts can open ep files and issue AIO without init-namespace root.
UI:N - The attacker performs io_submit and io_cancel/io_destroy on their own FunctionFS endpoint fds. No separate victim action is required beyond an already-deployed FunctionFS gadget.
S:U - The use-after-free corrupts kernel heap (ffs_io_data) within the same host kernel security authority. This is ordinary local privilege escalation, not a VM escape or IOMMU/sandbox boundary cross.
C:H - Use-after-free of ffs_io_data: ffs_aio_cancel() reads kiocb->private after kfree. Reclaim of that kmalloc object lets the attacker control io_data->ep/req and leak kernel memory via UDC dequeue; UAFs are scored High for confidentiality.
I:H - A reclaimed ffs_io_data yields attacker-controlled pointers passed to usb_ep_dequeue() from ffs_aio_cancel, providing a heap write and control-flow hijack primitive. Kernel UAFs are scored High for integrity.
A:H - Dereferencing the freed ffs_io_data in ffs_aio_cancel causes kernel oops/panic even without a full exploit; any such crash is High availability impact.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The UAF is in FunctionFS epfile AIO (ffs_epfile_write_iter/read_iter via io_submit/io_cancel on functionfs ep files), a local syscall path. ffs_epfile_io() can fail with -EAGAIN on O_NONBLOCK before any USB host is involved; this is the gadget userspace API, matching CVE-2024-36894/CVE-2026-63894 as Local rather than Physical.
AC:L - The attacker controls both sides: one thread io_submits AIO that fails after kiocb_set_cancel_fn (O_NONBLOCK -EAGAIN, halt, -EFAULT), while another calls io_cancel/io_destroy. The race between kfree(p) and aio_remove_iocb is freely retryable, so a race the attacker creates is AC:L.
PR:L - FunctionFS mounts commonly use uid=/gid=/fmode= to delegate ep files to unprivileged gadget daemons (adbd/shell on Android, MTP, embedded USB services). Once mounted by init, those accounts can open ep files and issue AIO without init-namespace root.
UI:N - The attacker performs io_submit and io_cancel/io_destroy on their own FunctionFS endpoint fds. No separate victim action is required beyond an already-deployed FunctionFS gadget.
S:U - The use-after-free corrupts kernel heap (ffs_io_data) within the same host kernel security authority. This is ordinary local privilege escalation, not a VM escape or IOMMU/sandbox boundary cross.
C:H - Use-after-free of ffs_io_data: ffs_aio_cancel() reads kiocb->private after kfree. Reclaim of that kmalloc object lets the attacker control io_data->ep/req and leak kernel memory via UDC dequeue; UAFs are scored High for confidentiality.
I:H - A reclaimed ffs_io_data yields attacker-controlled pointers passed to usb_ep_dequeue() from ffs_aio_cancel, providing a heap write and control-flow hijack primitive. Kernel UAFs are scored High for integrity.
A:H - Dereferencing the freed ffs_io_data in ffs_aio_cancel causes kernel oops/panic even without a full exploit; any such crash is High availability impact.
CVSS 3.1