CVE-2026-80920: io_uring: defer eventfd signaling when queued from a wakeup handler
In the Linux kernel, the following vulnerability has been resolved:
iouring: defer eventfd signaling when queued from a wakeup handler
ioreqlocalworkadd() signals the CQ ring eventfd inline when it is the one to push the first entry onto ->worklist. For DEFERTASKRUN rings that add is frequently done from a waitqueue wakeup handler, where an arbitrary waitqueue lock is held.
eventfdsignalmask() only refuses to recurse when current->ineventfd is set, but that bit is set by eventfdsignalmask() itself. If the wake chain starts somewhere else, signal goes out inline and can feed back into epoll.
Add IOUFTWQINWAKE, set it on the taskwork add done from the three waitqueue callbacks, and use it to force ioeventfdsignal() down the existing callrcuhurry() deferral instead of signaling inline.
Event History
Frequently Asked Questions
What conditions are needed to trigger the vulnerable path?
The affected path involves an io_uring ring using DEFER_TASKRUN, where local task work is added from one of the waitqueue wakeup callbacks. The issue arises when that addition is the first entry placed on the work list and eventfd signaling occurs while an arbitrary waitqueue lock is held.
What interaction makes this issue significant?
Inline eventfd signaling from the wakeup handler can feed back into epoll if the eventfd wake chain originated elsewhere. The existing eventfd recursion guard may not prevent that path because it is set only by eventfd_signal_mask() itself.
What does the fix change?
The fix marks task-work additions made by the three waitqueue callbacks and forces their eventfd notifications through the existing call_rcu_hurry() deferred path. This avoids signaling the eventfd inline while handling the waitqueue wakeup.