{"api_version":"1","generated_at":"2026-11-06T18:30:48+00:00","cve":"CVE-2026-99253","urls":{"html":"https://cve.report/CVE-2026-99253","api":"https://cve.report/api/cve/CVE-2026-99253.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-99253","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-99253"},"summary":{"title":"io_uring/cancel: rearm local work wake up before sleep","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/cancel: rearm local work wake up before sleep\n\nio_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next\nio_req_local_work_add() wakes the cancelling task. The add that takes the\ncount to zero is the only one that wakes, later ones see a count <= 0 and\nreturn. io_uring_cancel_generic() however only becomes\nTASK_INTERRUPTIBLE much later, so the one wake up can be spent on a\nrunning task. That is fine as long as the entry of that add is still\nqueued, as the io_local_work_pending() check then skips the sleep. It is\nnot if the add was delayed after queueing its entry:\n\nCPU0 (submitter in exec or exit)      CPU1 (io_req_local_work_add)\n                                      mpscq_push(req A)\nio_uring_try_cancel_requests()\n  io_run_local_work()  // runs req A\nio_uring_try_cancel_requests()\n  atomic_set(&ctx->cq_wait_nr, 1)\n                                      atomic_read(&ctx->cq_wait_nr) == 1\n                                      count taken, wake_up_state()\n                                        // task is running, no-op\nprepare_to_wait(TASK_INTERRUPTIBLE)\nio_local_work_pending() == false\nschedule()\n                                      mpscq_push(req B)\n                                      cq_wait_nr <= 0, return\n\nOnly the sleeping task can run req B, so it is stuck in execve() until a\nsignal happens to wake it. An exiting task doesn't even get that.\n\nArm the count again once the task state is set and before the work list\nis checked, for the rings whose local work this task is the one to run.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-11-03 12:17:32","updated_at":"2026-11-06 18:18:33"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/aaa06bb9fc03384f7cf2dbc3e43f2939cc7791b2","name":"https://git.kernel.org/stable/c/aaa06bb9fc03384f7cf2dbc3e43f2939cc7791b2","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/76a82c666abf155ad52d5f41043eac77dd3e41d8","name":"https://git.kernel.org/stable/c/76a82c666abf155ad52d5f41043eac77dd3e41d8","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/58ddf0ec707093206a5fe814581ec5aefac8b08a","name":"https://git.kernel.org/stable/c/58ddf0ec707093206a5fe814581ec5aefac8b08a","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-99253","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99253","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d46ab2c98ababa19b41a5709b6921d7b1add7f74 aaa06bb9fc03384f7cf2dbc3e43f2939cc7791b2 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d46ab2c98ababa19b41a5709b6921d7b1add7f74 58ddf0ec707093206a5fe814581ec5aefac8b08a git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d46ab2c98ababa19b41a5709b6921d7b1add7f74 76a82c666abf155ad52d5f41043eac77dd3e41d8 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 7.2","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.14 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3.2 7.3.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.4-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["io_uring/cancel.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"aaa06bb9fc03384f7cf2dbc3e43f2939cc7791b2","status":"affected","version":"d46ab2c98ababa19b41a5709b6921d7b1add7f74","versionType":"git"},{"lessThan":"58ddf0ec707093206a5fe814581ec5aefac8b08a","status":"affected","version":"d46ab2c98ababa19b41a5709b6921d7b1add7f74","versionType":"git"},{"lessThan":"76a82c666abf155ad52d5f41043eac77dd3e41d8","status":"affected","version":"d46ab2c98ababa19b41a5709b6921d7b1add7f74","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["io_uring/cancel.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"7.2"},{"lessThan":"7.2","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.14","versionType":"semver"},{"lessThanOrEqual":"7.3.*","status":"unaffected","version":"7.3.2","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.4-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.14","versionStartIncluding":"7.2","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3.2","versionStartIncluding":"7.2","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.4-rc1","versionStartIncluding":"7.2","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/cancel: rearm local work wake up before sleep\n\nio_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next\nio_req_local_work_add() wakes the cancelling task. The add that takes the\ncount to zero is the only one that wakes, later ones see a count <= 0 and\nreturn. io_uring_cancel_generic() however only becomes\nTASK_INTERRUPTIBLE much later, so the one wake up can be spent on a\nrunning task. That is fine as long as the entry of that add is still\nqueued, as the io_local_work_pending() check then skips the sleep. It is\nnot if the add was delayed after queueing its entry:\n\nCPU0 (submitter in exec or exit)      CPU1 (io_req_local_work_add)\n                                      mpscq_push(req A)\nio_uring_try_cancel_requests()\n  io_run_local_work()  // runs req A\nio_uring_try_cancel_requests()\n  atomic_set(&ctx->cq_wait_nr, 1)\n                                      atomic_read(&ctx->cq_wait_nr) == 1\n                                      count taken, wake_up_state()\n                                        // task is running, no-op\nprepare_to_wait(TASK_INTERRUPTIBLE)\nio_local_work_pending() == false\nschedule()\n                                      mpscq_push(req B)\n                                      cq_wait_nr <= 0, return\n\nOnly the sleeping task can run req B, so it is stuck in execve() until a\nsignal happens to wake it. An exiting task doesn't even get that.\n\nArm the count again once the task state is set and before the work list\nis checked, for the rings whose local work this task is the one to run."}],"providerMetadata":{"dateUpdated":"2026-11-06T17:15:12.869Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/aaa06bb9fc03384f7cf2dbc3e43f2939cc7791b2"},{"url":"https://git.kernel.org/stable/c/58ddf0ec707093206a5fe814581ec5aefac8b08a"},{"url":"https://git.kernel.org/stable/c/76a82c666abf155ad52d5f41043eac77dd3e41d8"}],"title":"io_uring/cancel: rearm local work wake up before sleep","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-99253","datePublished":"2026-11-03T11:20:12.490Z","dateReserved":"2026-09-25T10:25:14.403Z","dateUpdated":"2026-11-06T17:15:12.869Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-11-03 12:17:32","lastModifiedDate":"2026-11-06 18:18:33","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"99253","Ordinal":"1","Title":"io_uring/cancel: rearm local work wake up before sleep","CVE":"CVE-2026-99253","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"99253","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/cancel: rearm local work wake up before sleep\n\nio_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next\nio_req_local_work_add() wakes the cancelling task. The add that takes the\ncount to zero is the only one that wakes, later ones see a count <= 0 and\nreturn. io_uring_cancel_generic() however only becomes\nTASK_INTERRUPTIBLE much later, so the one wake up can be spent on a\nrunning task. That is fine as long as the entry of that add is still\nqueued, as the io_local_work_pending() check then skips the sleep. It is\nnot if the add was delayed after queueing its entry:\n\nCPU0 (submitter in exec or exit)      CPU1 (io_req_local_work_add)\n                                      mpscq_push(req A)\nio_uring_try_cancel_requests()\n  io_run_local_work()  // runs req A\nio_uring_try_cancel_requests()\n  atomic_set(&ctx->cq_wait_nr, 1)\n                                      atomic_read(&ctx->cq_wait_nr) == 1\n                                      count taken, wake_up_state()\n                                        // task is running, no-op\nprepare_to_wait(TASK_INTERRUPTIBLE)\nio_local_work_pending() == false\nschedule()\n                                      mpscq_push(req B)\n                                      cq_wait_nr <= 0, return\n\nOnly the sleeping task can run req B, so it is stuck in execve() until a\nsignal happens to wake it. An exiting task doesn't even get that.\n\nArm the count again once the task state is set and before the work list\nis checked, for the rings whose local work this task is the one to run.","Type":"Description","Title":"io_uring/cancel: rearm local work wake up before sleep"}]}}}