CVE-2026-99255: Linux Vulnerability

Description

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.

Metrics

EPSS Probability

0.20%

9.5th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 768134d4f48109b90f4248feecbeeb7d684e410c, < 98470f164286f7f62aaee519d4d11b9370ce6d7b; >= 768134d4f48109b90f4248feecbeeb7d684e410c, < d39ebc7a583d650b1d6da9b45e2ce96ad4d877e4; >= 768134d4f48109b90f4248feecbeeb7d684e410c, < ebe8e97fb99d9f374c482902a00677cfd24a6c27; >= 768134d4f48109b90f4248feecbeeb7d684e410c, < 3e02b8df0e9fa1423ac2a4e03409a9329c30ac49; >= 768134d4f48109b90f4248feecbeeb7d684e410c, < 92e20e9c72bdf6cfa6f84eded7b33399bc7061da; >= 768134d4f48109b90f4248feecbeeb7d684e410c, < 59e45f44c3cea9f4b2d099171c3cec1d25c5b638; >= 768134d4f48109b90f4248feecbeeb7d684e410c, < 436d48a2ed13112d2d27085325838e5bce6b4507
Linux	Linux	5.5

References

Timeline

Published: Nov 3, 2026
Last Modified: Nov 6, 2026
Status: Received

Frequently Asked Questions

What is CVE-2026-99255?

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.

How severe is CVE-2026-99255?

Severity scoring for CVE-2026-99255 is pending analysis. The EPSS model estimates a 0.20% probability of exploitation in the next 30 days.

How do I fix CVE-2026-99255?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →