{"api_version":"1","generated_at":"2026-09-24T17:37:33+00:00","cve":"CVE-2026-93220","urls":{"html":"https://cve.report/CVE-2026-93220","api":"https://cve.report/api/cve/CVE-2026-93220.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-93220","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-93220"},"summary":{"title":"sched_ext: Keep kick_sync waiting on the rq's own CPU","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Keep kick_sync waiting on the rq's own CPU\n\nkick_sync_wait_bal_cb() assumes it runs on the rq's CPU from the\n__schedule() tail: the snapshots it compares against live in that CPU's\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's next wait\npicks up the stale cpus_to_sync bits.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-24 16:17:17","updated_at":"2026-09-24 16:17:17"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/c736ea0fe7b4df920da6bd43a81c5eeecadcc8be","name":"https://git.kernel.org/stable/c/c736ea0fe7b4df920da6bd43a81c5eeecadcc8be","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/e0253dd04beb03e79477c5ef4768b11135687206","name":"https://git.kernel.org/stable/c/e0253dd04beb03e79477c5ef4768b11135687206","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-93220","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-93220","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4c95380701f58b8112f0b891de8d160e4199e19d c736ea0fe7b4df920da6bd43a81c5eeecadcc8be git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4c95380701f58b8112f0b891de8d160e4199e19d e0253dd04beb03e79477c5ef4768b11135687206 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.19","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.19 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.4 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-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":["kernel/sched/ext/ext.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"c736ea0fe7b4df920da6bd43a81c5eeecadcc8be","status":"affected","version":"4c95380701f58b8112f0b891de8d160e4199e19d","versionType":"git"},{"lessThan":"e0253dd04beb03e79477c5ef4768b11135687206","status":"affected","version":"4c95380701f58b8112f0b891de8d160e4199e19d","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["kernel/sched/ext/ext.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.19"},{"lessThan":"6.19","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.4","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.4","versionStartIncluding":"6.19","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc1","versionStartIncluding":"6.19","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Keep kick_sync waiting on the rq's own CPU\n\nkick_sync_wait_bal_cb() assumes it runs on the rq's CPU from the\n__schedule() tail: the snapshots it compares against live in that CPU's\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's next wait\npicks up the stale cpus_to_sync bits."}],"providerMetadata":{"dateUpdated":"2026-09-24T15:10:43.770Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/c736ea0fe7b4df920da6bd43a81c5eeecadcc8be"},{"url":"https://git.kernel.org/stable/c/e0253dd04beb03e79477c5ef4768b11135687206"}],"title":"sched_ext: Keep kick_sync waiting on the rq's own CPU","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-93220","datePublished":"2026-09-24T15:10:43.770Z","dateReserved":"2026-09-17T16:02:15.094Z","dateUpdated":"2026-09-24T15:10:43.770Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-24 16:17:17","lastModifiedDate":"2026-09-24 16:17:17","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"93220","Ordinal":"1","Title":"sched_ext: Keep kick_sync waiting on the rq's own CPU","CVE":"CVE-2026-93220","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"93220","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Keep kick_sync waiting on the rq's own CPU\n\nkick_sync_wait_bal_cb() assumes it runs on the rq's CPU from the\n__schedule() tail: the snapshots it compares against live in that CPU's\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's next wait\npicks up the stale cpus_to_sync bits.","Type":"Description","Title":"sched_ext: Keep kick_sync waiting on the rq's own CPU"}]}}}