CVE-2026-99263 in Linux
Summary
by MITRE • 11/03/2026
In the Linux kernel, the following vulnerability has been resolved:
io_uring/poll: avoid retry wakeup loss when dropping ownership
If a wakeup sets IO_POLL_RETRY_FLAG between the owning task consuming the existing instance of IO_POLL_RETRY_FLAG and the loop check of io_poll_check_events(), then we stall on processing the request until an unrelated wakeup comes along.
Using atomic_cmpxchg instead of atomic_sub_return to guarantee both the count v and poll_refs are 0 and no wake-ups are missed.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel's io_uring subsystem provides a powerful interface for asynchronous I/O operations, allowing applications to submit requests that can be processed in parallel with other system activities. Within this framework, polling mechanisms are critical for efficiently waiting on file descriptors without the overhead of traditional blocking calls. A specific race condition has been identified within the poll handling logic of io_uring, specifically concerning the management of retry flags and wake-up events. This vulnerability arises from a subtle timing issue in how ownership of poll instances is transferred and checked between tasks, leading to potential stalls where requests are not processed promptly despite being ready for completion.
The core technical flaw lies in the sequence of operations when handling IO_POLL_RETRY_FLAG. When an owning task consumes an existing instance of this flag, it must ensure that no new wake-up events occur simultaneously that would also set the retry flag. In the vulnerable implementation, there is a window between the consumption of the current retry state and the subsequent loop check in io_poll_check_events where a concurrent wakeup can set IO_POLL_RETRY_FLAG. Because the system does not atomically verify both the reference count and the poll references during this transition, it fails to detect that a wake-up has occurred but was missed due to the race condition. Consequently, the task stalls on processing the request, waiting for an unrelated future wakeup event rather than recognizing that work is already pending or completed.
This operational impact manifests as unnecessary latency in I/O operations and potential hangs in applications relying on io_uring for high-performance asynchronous tasks. The stall occurs because the kernel logic assumes no new events have arrived during the critical section of dropping ownership, which is an incorrect assumption under concurrent execution conditions. This can lead to degraded performance or even application-level timeouts if the unrelated wakeup never arrives within a reasonable timeframe. Such behavior undermines the reliability and efficiency guarantees that io_uring aims to provide, particularly in multi-threaded environments where multiple tasks may interact with the same poll instances concurrently.
From a classification perspective, this issue aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The race condition allows for a state inconsistency where the system fails to account for all pending events due to non-atomic updates of critical flags and counters. In terms of adversary behavior or attack surface analysis, while primarily a stability issue rather than a direct security exploit, it could potentially be leveraged in denial-of-service scenarios by inducing stalls that consume resources without progress. This maps loosely to ATT&CK techniques involving resource exhaustion or timing-based attacks against system services, although the primary vector here is accidental concurrency bugs rather than malicious exploitation.
The resolution involves replacing atomic_sub_return with atomic_cmpxchg operations to guarantee both the count and poll references are zero before proceeding. This change ensures that any wake-up events occurring during the transition of ownership are properly captured and do not get lost in the race window. By using compare-and-swap semantics, the kernel can atomically verify the state of the system and retry if necessary, thereby eliminating the possibility of missing a wakeup signal. This fix restores the correctness of the polling mechanism and ensures that io_uring requests are processed promptly without unnecessary delays caused by missed events.
To mitigate similar issues in other parts of the kernel or related subsystems, developers should prioritize atomic operations for any shared state that is accessed concurrently across multiple execution contexts. It is essential to ensure that checks for condition variables like retry flags and reference counts are performed atomically with respect to updates made by interrupt handlers or other threads. Regular code reviews focusing on race conditions in asynchronous I/O paths can help identify such vulnerabilities early. Additionally, stress testing io_uring applications under high concurrency can reveal timing-dependent bugs before they impact production environments. Maintaining up-to-date kernel versions that include this patch is the primary defense against experiencing these stalls and ensuring stable operation of async I/O workloads.