CVE-2026-80858 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
fuse: publish io-uring queues with release semantics
fuse_uring_create_queue() initializes a fuse_ring_queue and then publishes the pointer into ring->queues[qid] with WRITE_ONCE() under the
fch->lock. There are several readers that may concurrently be fetching that pointer locklessly and then deferencing it.
WRITE_ONCE() doesn't ensure ordering of the queue's field initialization before the ring->queues[qid] pointer assignment. The
queue must be published with smp_store_release() so the field initialization is guaranteed to happen before.
Readers in paths where the read may happen concurrently with the store need to use READ_ONCE() because any race involving a plain access is undefined.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel's FUSE (Filesystem in Userspace) subsystem contains a concurrency flaw within its io-uring queue management logic, specifically during the initialization and publication of ring queues. The function fuse_uring_create_queue is responsible for setting up a fuse_ring_queue structure before making it available to other parts of the system. During this process, the code uses WRITE_ONCE() to store the pointer to the newly initialized queue into the ring->queues array while holding the fch lock. While WRITE_ONCE ensures atomicity and prevents torn reads or writes on architectures where such operations are not naturally atomic, it does not provide any memory ordering guarantees regarding other memory accesses that occurred prior to this store operation. This distinction is critical in a multi-core environment where multiple threads may access shared data structures concurrently without explicit synchronization primitives like mutexes for every individual read.
The core technical flaw lies in the lack of proper release semantics when publishing the queue pointer. Because WRITE_ONCE does not enforce ordering, there exists a window where readers might observe the updated ring->queues[qid] pointer before the internal fields of the fuse_ring_queue structure have been fully initialized or written to memory by the writer thread. This creates a classic data race condition where concurrent readers, which fetch this locklessly and subsequently dereference it, may access uninitialized or partially initialized memory. In C programming terms, accessing an object that is being concurrently modified without proper synchronization constitutes undefined behavior, potentially leading to unpredictable system states, kernel panics, or silent corruption of internal state structures depending on the specific architecture and compiler optimizations involved.
From a security perspective, this vulnerability falls under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, specifically highlighting issues related to memory ordering and race conditions in concurrent programming. The lack of proper synchronization primitives means that an attacker who can influence or trigger the creation of FUSE io-uring queues might exploit this timing window. Although direct exploitation may be complex due to the need for precise timing and specific kernel states, such races often serve as building blocks for more sophisticated attacks, including privilege escalation if sensitive data is leaked from uninitialized memory regions or denial of service through kernel crashes caused by dereferencing invalid pointers derived from corrupted structures.
To mitigate this vulnerability, the code must be updated to use smp_store_release() instead of WRITE_ONCE when publishing the queue pointer into ring->queues[qid]. The smp_store_release function ensures that all prior memory writes are completed and visible to other processors before the store operation itself becomes visible, thereby establishing a happens-before relationship. Furthermore, readers in paths where access may occur concurrently with this publication must utilize READ_ONCE() for their loads. This pairing of release semantics on the write side and acquire-like behavior via READ_ONCE on the read side ensures that the initialization of the queue's fields is guaranteed to be visible before any reader attempts to dereference the pointer, effectively eliminating the race condition.
This fix aligns with best practices outlined in industry standards for concurrent kernel programming, emphasizing the importance of memory barriers and atomic operations with proper ordering semantics. It also relates to ATT&CK techniques involving exploitation of software vulnerabilities during system initialization or configuration changes, where timing windows can be leveraged by malicious actors. By enforcing strict memory ordering through appropriate synchronization primitives like smp_store_release and READ_ONCE, the kernel ensures data integrity across CPU cores, preventing undefined behavior and maintaining the stability and security of the FUSE subsystem under high-concurrency workloads involving io-uring operations.