This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Metrics
Affected Vendors & Products
| Vendors | Products |
|---|---|
| Linux |
|
No data.
No data.
References
History
Wed, 04 Nov 2026 18:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| Title | io_uring/timeout: don't lose a cancel as io-wq arms a timeout | |
| CPEs |
Tue, 03 Nov 2026 19:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Tue, 03 Nov 2026 14:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Linux linux
|
|
| Weaknesses | CWE-400 CWE-847 |
|
| Vendors & Products |
Linux linux
|
Tue, 03 Nov 2026 12:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | io_uring/timeout: don't lose a cancel as io-wq arms a timeout | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
|
MITRE
Status: REJECTED
Assigner: Linux
Published: 2026-11-03T11:48:15.294Z
Updated: 2026-11-04T18:21:44.261Z
Reserved: 2026-09-25T10:25:14.404Z
Link: CVE-2026-99262
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-11-03T12:17:33.210
Modified: 2026-11-03T20:18:31.763
Link: CVE-2026-99262
Redhat
No data.