CVE-2026-99265 in Linux
Summary
by MITRE • 11/03/2026
In the Linux kernel, the following vulnerability has been resolved:
io_uring/openclose: keep the lock in io_pipe_fixed()
io_pipe_fixed() installs both ends of the pipe in the fixed file table, drops ->uring_lock, and copies the slot numbers to the application. If that faults, it takes the lock again and removes whatever is in these slots.
If the request is run by io-wq the lock really is dropped in between, and the slots are visible to everybody else. By the time the error path gets to them, they may have been closed and reused, by IORING_OP_CLOSE and a direct open or accept, or by IORING_REGISTER_FILES_UPDATE. Then a file is removed from the table that has nothing to do with the failed request.
Do the copy with the lock held. Faulting in user memory under ->uring_lock is fine, the registration paths do it all the time.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified within the Linux kernel's io_uring subsystem represents a critical race condition rooted in improper synchronization during file descriptor management operations. Specifically, this flaw resides in the io_pipe_fixed function, which is responsible for installing both ends of a pipe into the fixed file table associated with an io_uring context. The core technical deficiency arises from the sequence of operations performed by this function: it installs the file descriptors, subsequently drops the ->uring_lock to allow other threads or work queues to proceed, and only then attempts to copy slot numbers back to user space memory. This design choice creates a temporal window where the state change is visible to concurrent actors before the operation has definitively completed or failed safely.
When an io_uring request is executed via the io-wq (io worker queue) mechanism, the lock release becomes particularly dangerous because it allows other threads within the same context to access and manipulate the file table slots that are currently being populated by the failing operation. If the subsequent copy-to-user operation triggers a page fault or memory error, the kernel enters an error handling path intended to clean up the partially completed registration. However, due to the lock having been dropped earlier in the process, the slot numbers involved may no longer belong to the original pipe endpoints. Instead, they might have been closed and reallocated by other concurrent operations such as IORING_OP_CLOSE, direct open calls, accept system calls, or updates via IORING_REGISTER_FILES_UPDATE.
This race condition leads to a severe integrity violation where the kernel attempts to remove a file descriptor from the fixed table that is unrelated to the failed request. By cleaning up resources based on stale or reused slot identifiers rather than the original intended targets, the vulnerability effectively results in the unintended closure of active files belonging to other processes or contexts within the same io_uring instance. This can lead to data corruption, denial of service for legitimate operations relying on those file descriptors, and potentially privilege escalation if an attacker can manipulate which files are closed through carefully timed concurrent requests. The flaw is categorized under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'), as the issue stems directly from accessing shared state without holding the necessary mutual exclusion lock during a critical section of memory interaction and resource management.
From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK technique T1059: Command and Scripting Interpreter or more broadly T1078: Valid Accounts if leveraged to disrupt service availability within containerized environments that rely heavily on io_uring for high-performance I/O operations. The ability to close arbitrary file descriptors can be exploited to degrade system stability, interfere with logging mechanisms, or cause application crashes by severing critical communication channels unexpectedly.
The resolution implemented in the kernel addresses this issue by enforcing strict serialization of the entire operation sequence. Specifically, the fix mandates that the copy-to-user operation must occur while holding the ->uring_lock. This ensures atomicity between the installation of file descriptors and their notification to user space, eliminating the window where slots could be reallocated or closed by concurrent threads. Although copying data under a spinlock is generally discouraged due to potential sleepability issues with page faults, in this specific context within io_uring, faulting in user memory while holding ->uring_lock is an established and safe pattern used extensively throughout the registration paths of the subsystem. This approach guarantees that no other thread can modify the fixed file table slots until the current operation has either fully succeeded or safely rolled back without affecting unrelated resources.
Mitigation strategies for systems running vulnerable versions include applying the latest kernel patches provided by distribution vendors, which incorporate this synchronization fix. For environments where immediate patching is not feasible, administrators should monitor for unusual termination of io_uring-based applications and ensure that file descriptor limits are configured appropriately to limit blast radius in case of instability. Furthermore, developers utilizing io_uring should be aware of the importance of holding locks during memory access operations involving fixed files to prevent similar race conditions in custom implementations or out-of-tree modules.