CVE-2026-64259: fuse-uring: make a fuse_req on SQE commit only findable after memcpy
In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: make a fusereq on SQE commit only findable after memcpy
Bad userspace might try to trick us and send commit SQEs request unique / commit-id of requests that are not even send to fuse-server (iouringcmddone() not called) yet.
fuseuringcommitfetch() ends the fuse request when the ring entry has a wrong state, but that could have caused a use-after-free with the memcpy operations in fuseuringsendintask(). In order to avoid such races the call of fuseuringaddtopq() is moved after the copy operations and just before completing the io-uring request - malicious userspace cannot find the request anymore until all prepration work in fuse-client/kernel is completed.
This also moves fuseuringaddtopq() a bit up in the code to avoid a forward declaration. Also not with a preparation commit, to make it easier to back port to older kernels.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel (fuse-uring)to a version that resolves this vulnerability.Fixed in Linux kernelPatch fuse-server (io_uring_cmd_done() not called) yet.
Event History
Frequently Asked Questions
Who is realistically exposed to exploitation?
Exploitation requires local access and low privileges. The vulnerable path involves malicious userspace interacting with FUSE through io_uring, rather than a remote network attacker.
What does an attacker need to do to trigger the race?
The attacker must submit commit SQEs using the request unique/commit ID of FUSE requests that have not yet been sent to the FUSE server or completed through io_uring_cmd_done(). This can cause request cleanup while memcpy operations are still in progress, resulting in a use-after-free.