AZL-112625: CVE-2026-99262 affecting package kernel 6.6.159.1-1
In the Linux kernel, the following vulnerability has been resolved:
iouring/timeout: don't lose a cancel as io-wq arms a timeout
An IORINGOPTIMEOUT run by io-wq, because of IOSQEASYNC, has the same problem as poll, futex and waitid. iowqsubmitwork() looks at IOWQWORKCANCEL once, before it issues the request. A cancel in between flags the work, gets -EALREADY, and searches ->timeoutlist in vain, while the worker then adds the request and starts the timer:
io-wq worker iotrycancel() iowqsubmitwork() IOWQWORKCANCEL isn't set ioasynccancelone() sets IOWQWORKCANCEL = -EALREADY iotimeoutcancel() = -ENOENT iotimeout() adds the request to ->timeoutlist hrtimerstart() = IOUISSUESKIPCOMPLETE
Nobody looks at the flag again, and the timeout runs its course. At ring exit, iouringtrycancelrequests() cancels io-wq work and then kills the timeouts the same way, so an exiting task can get stuck for the full duration of such a timeout.
Look at the flag under ->timeoutlock, which the search takes as well, and fail the request if it is set. If the search came first, the flag is visible. If it comes later, it finds the request on the list.
Affected Software
Event History
Frequently Asked Questions
Which workloads are exposed to this issue?
Workloads that submit IORING_OP_TIMEOUT requests through io_uring with IOSQE_ASYNC can encounter the race, because the timeout is armed by an io-wq worker. The issue depends on a cancellation arriving after the worker's initial cancellation-flag check but before the timeout is added to the timeout list.
What symptom may indicate that a system is affected?
A cancellation attempt can return -EALREADY while the timeout cancellation search returns -ENOENT, after which the timeout remains active and runs for its full duration. When the ring is being exited, the exiting task can become stuck until that timeout expires.