GHSA-QF92-WX54-FH27
Vulnerability from github – Published: 2026-11-03 12:31 – Updated: 2026-11-03 21:32In the Linux kernel, the following vulnerability has been resolved:
io_uring/mpscq: disable preemption while pushing
A push makes the node the new tail, and then links it to its predecessor. In between the queue isn't empty, but mpscq_pop() can't get at the node. The consumers deal with that by trying again, with a cond_resched() in the loop to give a preempted producer the chance to finish.
cond_resched() doesn't do that if the consumer has a higher priority than the producer and both have to use the same CPU:
producer (SCHED_OTHER) consumer (SCHED_FIFO), same CPU io_req_local_work_add() mpscq_push() prev = xchg(&q->tail, node) io_cqring_wait() __io_run_local_work() again: cond_resched() // nothing to do mpscq_pop() // NULL // work pending, no events yet goto again
The producer can be any task that is able to queue task_work for the ring: an io-wq worker, or somebody who sends a message with IORING_OP_MSG_RING. The consumer spins, holding ->uring_lock, until the scheduler takes pity on the fair class, which takes about a second with the default settings of the fair server, and forever without it. The loops in tctx_task_work_run() and io_cancel_local_task_work() have the same problem.
Don't allow preemption between the two steps. That bounds the time the window is open on the CPU of the producer by what interrupts take, and a consumer that waits for that is on another CPU. The cost is a preempt_disable()/preempt_enable() pair per push.
{
"affected": [],
"aliases": [
"CVE-2026-99252"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-11-03T12:17:31Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/mpscq: disable preemption while pushing\n\nA push makes the node the new tail, and then links it to its predecessor.\nIn between the queue isn\u0027t empty, but mpscq_pop() can\u0027t get at the node.\nThe consumers deal with that by trying again, with a cond_resched() in\nthe loop to give a preempted producer the chance to finish.\n\ncond_resched() doesn\u0027t do that if the consumer has a higher priority than\nthe producer and both have to use the same CPU:\n\n producer (SCHED_OTHER) consumer (SCHED_FIFO), same CPU\n io_req_local_work_add()\n mpscq_push()\n prev = xchg(\u0026q-\u003etail, node)\n \u003cpreempted\u003e io_cqring_wait()\n __io_run_local_work()\n again:\n cond_resched() // nothing to do\n mpscq_pop() // NULL\n // work pending, no events yet\n goto again\n\nThe producer can be any task that is able to queue task_work for the\nring: an io-wq worker, or somebody who sends a message with\nIORING_OP_MSG_RING. The consumer spins, holding -\u003euring_lock, until the\nscheduler takes pity on the fair class, which takes about a second with\nthe default settings of the fair server, and forever without it. The\nloops in tctx_task_work_run() and io_cancel_local_task_work() have the\nsame problem.\n\nDon\u0027t allow preemption between the two steps. That bounds the time the\nwindow is open on the CPU of the producer by what interrupts take, and a\nconsumer that waits for that is on another CPU. The cost is a\npreempt_disable()/preempt_enable() pair per push.",
"id": "GHSA-qf92-wx54-fh27",
"modified": "2026-11-03T21:32:06Z",
"published": "2026-11-03T12:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99252"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/68a95c3968895cd198f42baadb23e635fecc5a66"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c94677e2b6145393d4c129fe0f5364b0e5000a5"
}
],
"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
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.