CVE-2026-64260 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: Avoid queue->stopped races and set/read that value under lock
There are several readers of queue->stopped that check the value under lock, but fuse_uring_commit_fetch() did not and actually the value was not set under the lock in fuse_uring_abort_end_requests() either. Especially in fuse_uring_commit_fetch it is important to check under a lock, because due to races 'struct fuse_req' might be freed with fuse_request_end, but another thread/cpu might already do teardown work.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability described represents a critical race condition within the Linux kernel's fuse-uring subsystem that compromises system stability and potentially enables privilege escalation attacks. This issue specifically affects the interaction between multiple threads accessing shared data structures in the fuse filesystem implementation, where proper synchronization mechanisms have been inadequately applied. The problem manifests in the improper handling of the queue->stopped flag, which serves as a critical control mechanism for coordinating asynchronous operations within the unified I/O submission and completion ring architecture.
The technical flaw stems from inconsistent locking practices across different functions within the fuse-uring implementation. While some readers properly acquire locks before checking the queue->stopped value, the function fuse_uring_commit_fetch() fails to implement this protective measure, creating opportunities for data races that can lead to use-after-free conditions and memory corruption. Additionally, the fuse_uring_abort_end_requests() function does not properly serialize access to the queue->stopped flag by setting it under lock protection, further exacerbating the race condition landscape. This inconsistency in synchronization creates a scenario where threads may observe inconsistent state information, leading to unpredictable behavior when multiple CPUs attempt concurrent access to shared resources.
The operational impact of this vulnerability extends beyond simple system instability, potentially enabling malicious actors to exploit the race conditions for privilege escalation or denial-of-service attacks. When fuse_request_end() completes its work and frees memory structures, but another thread has already initiated teardown operations, the system faces a critical timing window where memory corruption can occur. This scenario directly violates fundamental principles of concurrent programming and can result in kernel panics, data loss, or unauthorized access to system resources. The vulnerability affects systems utilizing the fuse-uring subsystem, particularly those running modern Linux kernels with unified I/O capabilities and high-concurrency workloads.
The mitigation approach requires implementing consistent locking mechanisms throughout the fuse-uring subsystem to ensure atomic access to the queue->stopped flag and related synchronization primitives. This involves modifying both fuse_uring_commit_fetch() and fuse_uring_abort_end_requests() functions to acquire appropriate locks before reading or writing the queue->stopped value, thereby preventing race conditions that could lead to memory corruption. Security practitioners should prioritize kernel updates that address this specific race condition, as well as implement monitoring for unusual system behavior that might indicate exploitation attempts. The fix aligns with common security practices outlined in the CWE catalog under category 362 for concurrent execution use of lock objects and follows ATT&CK framework techniques related to privilege escalation through kernel vulnerabilities. Organizations should also consider implementing additional defensive measures such as kernel hardening configurations and runtime integrity monitoring to detect potential exploitation attempts targeting this class of race condition vulnerabilities.