GHSA-MP4R-853F-VHWR
Vulnerability from github – Published: 2026-09-24 18:31 – Updated: 2026-09-24 18:31In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Keep kick_sync waiting on the rq's own CPU
kick_sync_wait_bal_cb() assumes it runs on the rq's CPU from the __schedule() tail: the snapshots it compares against live in that CPU's percpu area and the busy-wait runs with the rq lock dropped and IRQs enabled.
However, dispatch can now drop the rq lock while the callback sits queued, and rq lock takers in that window (the sched class change paths, the scx task iterator) flush pending balance callbacks on release, running the callback on a foreign CPU. Such a run compares against unrelated snapshots and can deadlock when the executing CPU is itself a wait target.
Bail on a foreign CPU and leave the wait state alone. The wait only observes progress that the resched kicks already guarantee and the rq's next wait picks up the stale cpus_to_sync bits.
{
"affected": [],
"aliases": [
"CVE-2026-93220"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-24T16:17:17Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Keep kick_sync waiting on the rq\u0027s own CPU\n\nkick_sync_wait_bal_cb() assumes it runs on the rq\u0027s CPU from the\n__schedule() tail: the snapshots it compares against live in that CPU\u0027s\npercpu area and the busy-wait runs with the rq lock dropped and IRQs\nenabled.\n\nHowever, dispatch can now drop the rq lock while the callback sits queued,\nand rq lock takers in that window (the sched class change paths, the scx\ntask iterator) flush pending balance callbacks on release, running the\ncallback on a foreign CPU. Such a run compares against unrelated snapshots\nand can deadlock when the executing CPU is itself a wait target.\n\nBail on a foreign CPU and leave the wait state alone. The wait only observes\nprogress that the resched kicks already guarantee and the rq\u0027s next wait\npicks up the stale cpus_to_sync bits.",
"id": "GHSA-mp4r-853f-vhwr",
"modified": "2026-09-24T18:31:22Z",
"published": "2026-09-24T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93220"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c736ea0fe7b4df920da6bd43a81c5eeecadcc8be"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e0253dd04beb03e79477c5ef4768b11135687206"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.
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.