Cloudanix VulnDB

CVE-2026-99255

None

CVSS

—

EPSS

0.2%

Published

Nov 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel can cause programs that use advanced input-output features to get stuck forever when they try to shut down.

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

Race condition in io_uring/io-wq cancellation logic creates a window during linked request handling where a subsequent request is neither pending, assigned as current worker work, nor on the cancellation list, allowing io_uring_cancel_generic to miss it during task exit and leave the exiting task permanently blocked.

Why it matters to the business

Applications using io_uring with linked requests may experience indefinite hangs on thread or process exit, reducing system reliability, complicating graceful shutdowns, and increasing operational overhead in environments with heavy asynchronous I/O workloads.

How an attack unfolds

An attacker submits a chain of linked io_uring requests (for example NOP followed by FUTEX_WAIT) and forces task exit at the precise moment io_wq_free_work removes the link but before the next request is parked, causing the cancellation pass to sleep permanently with IO_WQ_BIT_EXIT ineffective for bounded work.

How to fix it

Apply the upstream fix that splits io_wq_free_work so the request is freed only after the link becomes the current worker work or is placed on a list visible to cancellations; rebuild and deploy the patched kernel across all affected systems.

How to confirm the fix worked

Boot the patched kernel, repeatedly exercise linked io_uring workloads with concurrent task exits, and confirm absence of hangs in io_uring_cancel_generic/do_exit paths; monitor for the original timing window using kernel tracing.

Typical attack path

  1. Submit linked io_uring requests using IOSQE_IO_LINK
  2. Trigger rapid task exit (thread or process) during the narrow window after io_req_find_next but before the link is reassigned
  3. Leave the task blocked in io_uring_cancel_generic with no completion or wakeup occurring

How to detect it

Search kernel logs and process traces for threads blocked in io_uring_cancel_generic during do_exit; correlate with io_uring request chains that include IOSQE_IO_LINK and observe whether completions or wakeups are missing after task exit.

What your security team should do

  • Prioritize kernel upgrade on all systems running io_uring workloads within the next maintenance window
  • Temporarily restrict untrusted code from using IOSQE_IO_LINK until patches are deployed
  • Add monitoring for processes stuck in do_exit with io_uring references

The record

In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: don't hide a link from cancellations A task that exits cancels its tracked requests and waits until they are gone. io_uring_cancel_generic() looks everywhere a request can be, and goes to sleep if it found nothing to cancel. It is woken up each time one of the requests of the task is completed by task work or freed. When io-wq is done with a request that has a link, there is a time in which the next request of the link can't be found: io_worker_handle_work() io_assign_current_work(worker, NULL) io_wq_free_work(work) io_req_find_next() // takes the link off the request io_free_req() // task work for the task io_assign_current_work(worker, linked) io_run_task_work() cond_resched() worker->cur_work = linked It is not pending, it is not the current work of a worker, and it is not yet on the list that it is about to be parked on. If the pass that the exiting task makes because of io_free_req() falls into that time, it finds nothing and the task goes to sleep. The worker then runs the link, which IO_WQ_BIT_EXIT doesn't prevent for bounded work. If that parks the request nothing is completed or freed, and nobody wakes up the task. If it is the process that exits it can't be killed any more either. NOP, IOSQE_ASYNC | IOSQE_IO_LINK FUTEX_WAIT, FUTEX2_PRIVATE exit of the thread, or of the process, up to 63us later With four of these per round 5 to 8 of 10,000 rounds hang (4 CPUs, KVM): io_uring_cancel_generic do_exit Commit f8b632e89a10 ("io_uring: tighten task exit cancellations") is about the same gap, and makes the task look again for whatever happens before io_free_req(). Free the request once the link is the current work of the worker, or pending. Whoever is woken up by that can find the link, until it is parked where cancellations look as well. To do so split io_wq_free_work() in two.

Affected packages

Ecosystem Package Introduced Fixed