CVE-2026-23275 in Linux
Summary
by MITRE • 03/20/2026
In the Linux kernel, the following vulnerability has been resolved:
io_uring: ensure ctx->rings is stable for task work flags manipulation
If DEFER_TASKRUN | SETUP_TASKRUN is used and task work is added while the ring is being resized, it's possible for the OR'ing of IORING_SQ_TASKRUN to happen in the small window of swapping into the new rings and the old rings being freed.
Prevent this by adding a 2nd ->rings pointer, ->rings_rcu, which is protected by RCU. The task work flags manipulation is inside RCU already, and if the resize ring freeing is done post an RCU synchronize, then there's no need to add locking to the fast path of task work additions.
Note: this is only done for DEFER_TASKRUN, as that's the only setup mode that supports ring resizing. If this ever changes, then they too need to use the io_ctx_mark_taskrun() helper.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 05/23/2026
The vulnerability described in CVE-2026-23275 resides within the Linux kernel's io_uring subsystem, specifically addressing a race condition that can occur during task work flag manipulation when ring resizing operations are in progress. This issue affects the io_uring asynchronous I/O interface which is designed to provide high-performance asynchronous I/O operations for applications. The vulnerability manifests when the DEFER_TASKRUN and SETUP_TASKRUN flags are utilized in conjunction with ring resizing operations, creating a temporal window where inconsistent memory states can lead to improper flag handling.
The technical flaw stems from the lack of proper synchronization mechanisms during the transition period when io_uring rings are being resized. When task work is added to the system while the ring is in the process of being resized, there exists a critical race condition where the OR operation involving IORING_SQ_TASKRUN flag can be executed against either the old or new rings depending on timing. This occurs because the traditional rings pointer does not provide sufficient protection during the atomic swap operation between old and new ring structures, allowing for potential memory corruption or inconsistent flag states.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially compromising system stability and data integrity. Attackers could exploit this race condition to manipulate task work flags in ways that might lead to incorrect scheduling decisions, improper I/O completion handling, or even potential privilege escalation scenarios within the kernel context. The vulnerability is particularly concerning because it affects the core kernel I/O subsystem that is heavily utilized by applications requiring high-performance asynchronous operations, making it a significant target for exploitation in systems where io_uring is actively used.
The mitigation strategy implemented in this fix involves introducing a secondary rings pointer called ->rings_rcu which is protected by RCU (Read-Copy-Update) mechanisms. This approach leverages the existing RCU infrastructure already present in the task work flag manipulation code paths, avoiding the need for additional locking mechanisms on the fast path of task work additions. The solution specifically targets the DEFER_TASKRUN setup mode since that is the only configuration currently supporting ring resizing operations, though the implementation includes provisions for future expansion should other modes require similar protection. This approach aligns with common security best practices for concurrent systems and addresses the vulnerability through proper memory synchronization rather than broad locking mechanisms that could impact performance. The fix demonstrates adherence to security principles by minimizing performance overhead while ensuring correctness, and it follows established patterns for handling concurrent access in kernel code. This vulnerability classification aligns with CWE-362, which covers race conditions, and represents a classic example of improper synchronization in concurrent systems. The solution also reflects the ATT&CK framework's approach to kernel-level vulnerabilities, where improper memory management and synchronization can lead to privilege escalation and system instability. The implementation of RCU-based protection ensures that the fix maintains the performance characteristics of the io_uring subsystem while providing the necessary memory safety guarantees.