CVE-2026-99262

In the Linux kernel, the following vulnerability has been resolved:

io uring/timeout: don't lose a cancel as io-wq arms a timeout

An IORING OP TIMEOUT run by io-wq, because of IOSQE ASYNC, has the same problem as poll, futex and waitid. io wq submit work() looks at IO WQ WORK CANCEL once, before it issues the request. A cancel in between flags the work, gets -EALREADY, and searches ->timeout list in vain, while the worker then adds the request and starts the timer:

io-wq worker io try cancel() io wq submit work() IO WQ WORK CANCEL isn't set io async cancel one() sets IO WQ WORK CANCEL = -EALREADY io timeout cancel() = -ENOENT io timeout() adds the request to ->timeout list hrtimer start() = IOU ISSUE SKIP COMPLETE

Nobody looks at the flag again, and the timeout runs its course. At ring exit, io uring try cancel requests() 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 ->timeout lock, 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.