GHSA-74P5-P638-5CC7
Vulnerability from github – Published: 2026-10-28 12:31 – Updated: 2026-10-30 15:34In the Linux kernel, the following vulnerability has been resolved:
io_uring/cancel: don't spin on local work the task can't run
io_uring_cancel_generic() refuses to sleep while any ring on the exiting task's tctx has local work pending. It assumes the task is that ring's submitter and that the next io_uring_try_cancel_requests() pass will run the work. This does not hold for a ring that was still IORING_SETUP_R_DISABLED when the task got its tctx node from io_uring_create() or io_ringfd_register(). The submitter is set later by IORING_REGISTER_ENABLE_RINGS, possibly from another task, and only the submitter may run local work on an IORING_SETUP_DEFER_TASKRUN ring. To the exiting task the work stays pending forever, the loop never reaches schedule(), and the task trips the WARN_ON_ONCE() once and then spins in do_exit().
An unprivileged user can set this up at will by creating a disabled ring, having a child enable it and stop, posting to the ring with IORING_OP_MSG_RING and exiting with a request in flight that only the child can complete. The exiting thread burns a CPU until the child runs or dies, and with panic_on_warn set the WARN panics the kernel.
Fix by skipping the sleep only when io_allowed_defer_tw_run() allows the task to run the work. This is reasonable since work it cannot run cannot complete any of its requests either, so nothing is lost by sleeping. Drop the WARN_ON_ONCE() since handing a disabled ring to another thread is a supported scenario, not a bug state.
{
"affected": [],
"aliases": [
"CVE-2026-99130"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-28T11:17:32Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/cancel: don\u0027t spin on local work the task can\u0027t run\n\nio_uring_cancel_generic() refuses to sleep while any ring on the exiting\ntask\u0027s tctx has local work pending. It assumes the task is that ring\u0027s\nsubmitter and that the next io_uring_try_cancel_requests() pass will run\nthe work. This does not hold for a ring that was still\nIORING_SETUP_R_DISABLED when the task got its tctx node from\nio_uring_create() or io_ringfd_register(). The submitter is set later by\nIORING_REGISTER_ENABLE_RINGS, possibly from another task, and only the\nsubmitter may run local work on an IORING_SETUP_DEFER_TASKRUN ring. To\nthe exiting task the work stays pending forever, the loop never reaches\nschedule(), and the task trips the WARN_ON_ONCE() once and then spins in\ndo_exit().\n\nAn unprivileged user can set this up at will by creating a disabled\nring, having a child enable it and stop, posting to the ring with\nIORING_OP_MSG_RING and exiting with a request in flight that only the\nchild can complete. The exiting thread burns a CPU until the child runs\nor dies, and with panic_on_warn set the WARN panics the kernel.\n\nFix by skipping the sleep only when io_allowed_defer_tw_run() allows the\ntask to run the work. This is reasonable since work it cannot run cannot\ncomplete any of its requests either, so nothing is lost by sleeping.\nDrop the WARN_ON_ONCE() since handing a disabled ring to another thread\nis a supported scenario, not a bug state.",
"id": "GHSA-74p5-p638-5cc7",
"modified": "2026-10-30T15:34:22Z",
"published": "2026-10-28T12:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99130"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3005459e0ddfcef0f555b6e81f672f2c49a1c0aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64e196a6d7173667a2a0fe2f191bc64eecd07778"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a241d7ca23be2695a1fbe587ee12eae061c31af"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/94d13387b96e50a4288f7bbdfe401189246a11a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fddcf4c5321b3ea5f72166c3fd36a9d1c34f80c7"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.