CVE-2026-64259 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: make a fuse_req 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 (io_uring_cmd_done() not called) yet.
fuse_uring_commit_fetch() 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 fuse_uring_send_in_task(). In order to avoid such races the call of fuse_uring_add_to_pq() 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 fuse_uring_add_to_pq() 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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability described represents a critical race condition in the Linux kernel's fuse-uring implementation that could lead to use-after-free conditions and potential privilege escalation. This issue specifically affects the interaction between the io_uring subsystem and the fuse filesystem driver when processing completion events. The flaw occurs during the processing of submission queue entries where malicious userspace can exploit timing vulnerabilities to manipulate request states before proper initialization is complete.
The technical root cause involves improper ordering of operations within the fuse_uring_commit_fetch() function and related kernel code paths. When processing io_uring completion events, the system attempts to find and complete fuse requests based on unique identifiers and commit IDs. However, the original implementation allowed userspace to submit commit SQEs referencing requests that had not yet been properly sent to the fuse server, creating a window where request structures could be accessed after being freed. This violates fundamental memory safety principles and creates opportunities for attackers to execute arbitrary code or cause system instability.
From an operational perspective, this vulnerability exposes the Linux kernel to potential exploitation through malicious userspace processes that can craft specific io_uring requests designed to trigger the race condition. The use-after-free scenario could allow attackers to manipulate kernel memory structures, potentially leading to privilege escalation or denial of service conditions. The attack vector specifically targets the synchronization mechanisms between userspace and kernel space in the io_uring subsystem, making it particularly dangerous as it operates at a low level within the kernel's request processing pipeline. This aligns with CWE-416, which covers use-after-free vulnerabilities, and represents a classic race condition scenario where improper locking or ordering of operations creates exploitable timing windows.
The mitigation implemented addresses this by reordering the execution flow to ensure that fuse request structures are only made findable after all necessary preparation work has been completed. Specifically, the function fuse_uring_add_to_pq() is moved to occur after memcpy operations and just before completing the io_uring request, effectively eliminating the window where malicious userspace could reference already freed memory structures. This change prevents the race condition by ensuring that request lookup only occurs after all pre-processing is complete, as mandated by the principle of proper synchronization in concurrent systems. The fix also simplifies code structure by removing forward declarations and making the implementation more straightforward for backporting to older kernel versions, which aligns with ATT&CK technique T1068 related to exploit development for privilege escalation.
The solution demonstrates a robust approach to addressing concurrency issues in kernel space by ensuring proper ordering of operations and eliminating timing windows that could be exploited. By delaying the availability of request structures until after all preparation work is complete, the implementation prevents malicious userspace from manipulating kernel memory in unintended ways. This approach follows established security principles for kernel development where race conditions must be eliminated through careful ordering of operations rather than relying on complex locking mechanisms that could introduce additional vulnerabilities. The change also improves maintainability and reduces the complexity of the code path, making it easier to verify correct behavior and reducing the likelihood of similar issues in the future.