CVE-2026-90044
massUse-After-Free in Linux Kernel USB Gadget FunctionFS AIO Error Path
A use-after-free exists in the Linux kernel's USB gadget FunctionFS driver (f_fs), in the ffs_epfile_write_iter() and ffs_epfile_read_iter() functions. When an AIO (asynchronous I/O) operation fails with an error other than -EIOCBQUEUED, the io_data structure is freed while the kiocb cancellation handler is still armed and still points to that freed memory; a concurrent sys_io_cancel() call in that window dereferences the freed pointer. A local attacker with low privileges and access to a FunctionFS endpoint can trigger this race, gaining kernel memory corruption with potential for privilege escalation, since the CVSS impact is rated high for confidentiality, integrity, and availability (7.8, local vector). Affected systems are primarily Linux kernels with the f_fs gadget driver enabled, a configuration most common on Android devices (adbd uses FunctionFS) and embedded Linux boards acting as USB devices. No public proof-of-concept or exploitation in the wild is known, and the issue is not listed in CISA's KEV catalog.
What to do: Apply the upstream kernel patch (or a stable/vendor backport that un-arms the kiocb cancellation in the f_fs AIO error path); for Android, install vendor security updates that include this kernel fix. As mitigation, restrict read/write access to /dev/usb-ffs/* endpoint nodes to trusted processes and avoid running untrusted local code on affected devices. Check whether your kernel configuration enables CONFIG_USB_FUNCTIONFS and whether any components use AIO (io_submit/io_cancel) on FunctionFS endpoints.
| Linux kernel (USB gadget FunctionFS / f_fs driver) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Vector
- CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.