CVE-2026-80920 in Linux
Summary
by MITRE • 09/09/2026
In the Linux kernel, the following vulnerability has been resolved:
io_uring: defer eventfd signaling when queued from a wakeup handler
io_req_local_work_add() signals the CQ ring eventfd inline when it is the one to push the first entry onto ->work_list. For DEFER_TASKRUN rings that add is frequently done from a waitqueue wakeup handler, where an arbitrary waitqueue lock is held.
eventfd_signal_mask() only refuses to recurse when current->in_eventfd is set, but that bit is set by eventfd_signal_mask() itself. If the wake chain starts somewhere else, signal goes out inline and can feed back into epoll.
Add IOU_F_TWQ_IN_WAKE, set it on the task_work add done from the three waitqueue callbacks, and use it to force io_eventfd_signal() down the existing call_rcu_hurry() deferral instead of signaling inline.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The Linux kernel vulnerability identified in this advisory relates to a race condition within the io_uring subsystem, specifically concerning how event file descriptors are signaled during task work queue operations. The core issue arises from the interaction between the io_req_local_work_add function and waitqueue wakeup handlers. When an operation is queued for deferred execution on rings configured with DEFER_TASKRUN flags, the system often executes this queuing logic while holding arbitrary waitqueue locks inside a wakeup handler. In these scenarios, the code path attempts to signal completion by calling eventfd_signal_mask inline if it determines that it is pushing the first entry onto the work list. This immediate signaling mechanism creates a dangerous feedback loop because the signal can propagate back into epoll instances waiting on those file descriptors, potentially triggering further wakeups or context switches while critical locks are still held and recursion checks may be bypassed due to state management flaws in the eventfd subsystem.
The technical flaw stems from an incomplete recursive detection mechanism within the eventfd signaling logic. The function eventfd_signal_mask is designed to prevent infinite recursion by checking a flag on the current task structure, specifically current->in_eventfd. However, this protection only works if the initial signal originates from code that sets this bit before calling into the deeper layers of the signal handler chain. When the wake chain initiates from an external source rather than directly through eventfd_signal_mask itself, the recursive guard is not properly engaged. Consequently, a signal sent inline during a waitqueue wakeup can feed back into epoll, causing re-entrance issues that compromise kernel stability and potentially lead to denial of service conditions or unpredictable behavior in applications relying on io_uring for high-performance asynchronous I/O operations.
This vulnerability aligns with CWE-362, which describes concurrent execution errors involving race conditions, as the issue involves improper synchronization between task work queuing and event signaling mechanisms under specific lock contexts. From a threat modeling perspective using MITRE ATT&CK techniques, this flaw can be associated with T1059 Command Scripting or T1499 Endpoint Denial of Service if exploited to crash the system through recursive wakeups. The impact is primarily localized to systems utilizing io_uring with DEFER_TASKRUN semantics, where high-frequency I/O operations trigger these specific code paths frequently enough to expose the race condition. Attackers could potentially leverage this flaw to cause kernel panics or degrade system performance by inducing excessive context switching and lock contention through crafted asynchronous I/O requests that exploit the eventfd signaling loop.
The resolution implemented in the Linux kernel addresses this issue by introducing a new flag, IOU_F_TWQ_IN_WAKE, which explicitly marks task work additions performed from within waitqueue callbacks. By setting this flag during these specific operations, the code path is forced to defer the actual eventfd signal using io_eventfd_signal() routed through call_rcu_hurry(). This deferral ensures that signaling occurs outside of the critical section where waitqueue locks are held and avoids the problematic inline execution context entirely. This change breaks the recursive feedback loop by ensuring that signals are processed asynchronously after the wakeup handler has completed its work, thereby maintaining proper lock ordering and preventing re-entrance into epoll or other waiting mechanisms during sensitive kernel operations.
To mitigate this vulnerability in environments where immediate patching is not feasible, administrators should consider disabling io_uring if it is not strictly required for application performance. For systems that must rely on io_uring, ensuring that the operating system is updated to a version containing this specific fix is critical. Monitoring logs for kernel oops or panic messages related to eventfd or epoll can help detect potential exploitation attempts in real-time. Additionally, applying strict resource limits and monitoring for unusual spikes in context switches may provide early warning signs of abuse targeting this race condition. Organizations should prioritize updating their Linux kernels to versions that include the IOU_F_TWQ_IN_WAKE logic change to fully neutralize the risk associated with deferred task work signaling from wakeup handlers.