CVE-2026-99262: io_uring/timeout: don't lose a cancel as io-wq arms a timeout

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.