CVE-2026-99254

What it actually does

The flaw causes repeated task_work callbacks to be queued to an exiting task during io_uring ring cleanup when cancellation is active, creating a CPU-bound loop that prevents task_work_run from completing and blocks process exit or execve.

Why it matters to the business

Unprivileged local workloads using io_uring can induce sustained high CPU usage and unresponsive processes on affected kernels, disrupting services and requiring restarts or reboots with no external network access needed.

How an attack unfolds

An attacker creates multiple mutually polling io_uring rings, then triggers exit_group or execve; the exit work repeatedly re-queues callbacks to the same task because the cancellation path does not remove nodes promptly, resulting in hundreds of thousands of callbacks and CPU lockup until senders are delayed simultaneously.

How to fix it

Upgrade the Linux kernel to a version containing the io_uring task_work fix described in the resolution; apply distribution kernel updates as they become available.

How to confirm the fix worked

Verify updated kernel version; reproduce multi-ring polling exit scenario and confirm task_work_run completes without repeated callbacks or WARN_ON in io_ring_exit_work.

Typical attack path

1. Instantiate multiple interacting io_uring rings
2. Trigger process termination via exit_group or execve
3. Observe task_work loop consuming CPU and blocking cancellation

How to detect it

Inspect kernel logs for io_ring_exit_work timeouts or repeated task_work activity; correlate high-CPU exiting processes with io_uring usage; search dmesg for WARN_ON_ONCE(time_after(jiffies, timeout)).

• io_ring_exit_work
• io_tctx_exit_cb
• WARN_ON_ONCE(time_after(jiffies, timeout))
• task_work_run

What your security team should do

• Apply kernel updates immediately on systems exposing io_uring to untrusted workloads
• Monitor for io_ring_exit_work related CPU spikes
• Restrict io_uring usage via seccomp or LSM policies where feasible