Cloudanix VulnDB

CVE-2026-80920

None

CVSS

—

EPSS

0.2%

Published

Sep 9, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel's input/output handling could let specially crafted operations cause the system to become unstable or crash.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Inline eventfd signaling from waitqueue wakeup handlers in io_uring can recurse into epoll when the in_eventfd guard is not set by external wake chains, allowing unbounded signal delivery during task_work addition on DEFER_TASKRUN rings.

Why it matters to the business

Systems relying on io_uring for high-performance I/O may experience kernel instability, potential crashes, or degraded responsiveness under concurrent wakeup and event notification workloads.

How an attack unfolds

An attacker configures an io_uring instance with DEFER_TASKRUN, registers eventfds and epoll watches, then triggers waitqueue wakeups from other kernel paths so that io_req_local_work_add() performs inline eventfd_signal_mask() without the proper deferral flag, causing recursive epoll callbacks and resource exhaustion.

How to fix it

Apply the kernel patch that introduces IOU_F_TWQ_IN_WAKE and routes eventfd signaling through call_rcu_hurry() for wakeup-originated task_work additions; rebuild and deploy updated kernel images across all affected hosts.

How to confirm the fix worked

Boot the patched kernel, exercise io_uring rings under DEFER_TASKRUN with concurrent epoll and eventfd activity, and confirm absence of recursive signal paths via kernel tracing or lockdep reports.

Typical attack path

  1. Create io_uring ring with DEFER_TASKRUN and attach eventfd
  2. Register file descriptors that participate in waitqueue wakeups and epoll
  3. Trigger external wakeup sources that invoke the three waitqueue callbacks
  4. Force io_req_local_work_add() to execute while holding waitqueue locks
  5. Induce inline eventfd signal that feeds back into epoll and recurses

How to detect it

Review kernel logs for stack overflows or warnings related to eventfd recursion, inspect io_uring ring configurations for DEFER_TASKRUN combined with eventfd, and search audit or syscall traces for repeated eventfd_signal calls originating from waitqueue handlers.

What your security team should do

  • Prioritize kernel updates on any hosts exposing io_uring to untrusted workloads
  • Audit applications using io_uring with eventfd and epoll for DEFER_TASKRUN usage
  • Enable kernel lockdep and tracing in staging environments to validate the fix
  • Monitor upstream stable branches for backports of the io_uring deferral change

The record

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.

Affected packages

Ecosystem Package Introduced Fixed