GHSA-2W6G-3PWR-88WC
Vulnerability from github – Published: 2026-07-19 12:30 – Updated: 2026-07-20 15:31In the Linux kernel, the following vulnerability has been resolved:
sched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path
In mm_cid_fixup_cpus_to_tasks(), when rq->curr has the target mm and mm_cid.active is set, the CID is checked with cid_in_transit() before setting the transition bit. In per-CPU mode a newly forked or exec'd task can be running with mm_cid.cid == MM_CID_UNSET because CIDs are assigned lazily on schedule-in. With cid_in_transit() the guard passes for MM_CID_UNSET (no transit bit), converts it to MM_CID_UNSET | MM_CID_TRANSIT and stores it back; later mm_cid_schedout() feeds this to clear_bit() with MM_CID_UNSET as the bit number, triggering an out-of-bounds write.
Symptoms: this is genuine memory corruption, but a bounded out-of-bounds write, not an arbitrary one. MM_CID_UNSET is the fixed sentinel BIT(31), so once the bad value reaches mm_cid_schedout() the cid_from_transit_cid() strip leaves MM_CID_UNSET, which fails the "cid < max_cids" convergence test and falls into mm_drop_cid() -> clear_bit(MM_CID_UNSET, mm_cidmask(mm)). The cid bitmap is embedded in the mm_struct slab object (after cpu_bitmap and mm_cpus_allowed) and is only num_possible_cpus() bits wide, so clearing bit 31 is a deterministic OOB bit-clear at a fixed offset of 2^31 / 8 == 256 MiB past the bitmap base. The address is not attacker-influenced (fixed sentinel -> fixed offset) and the op only clears a single bit; what sits 256 MiB further along the direct map is whatever kernel object happens to live there, so this corrupts one bit of unpredictable kernel memory -- it is not an arbitrary-address or arbitrary-value write.
It triggers only in per-CPU CID mode, when a CPU is running an active task of the target mm whose cid is still MM_CID_UNSET -- the fork()/execve() window before that task's next schedule-in assigns it a real CID -- and a per-CPU -> per-task fixup walks over it (the mode fallback driven by a thread exit, sched_mm_cid_exit(), or by the deferred max_cids recompute in mm_cid_work_fn()).
In practice syzkaller surfaced it as a KASAN use-after-free reported in __schedule -> mm_cid_switch_to, where the offending clear_bit() is inlined via mm_cid_schedout() -> mm_drop_cid().
Guard the transition-bit assignment against MM_CID_UNSET, in addition to the existing cid_in_transit() check, so the bit is only set on a genuine task-owned CID. A CPU-owned (MM_CID_ONCPU) CID of a running active task is handled by the cid_on_cpu(pcp->cid) branch above and never reaches this path, so excluding MM_CID_UNSET (and the already-transitioning case) is sufficient.
{
"affected": [],
"aliases": [
"CVE-2026-63799"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T12:16:52Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path\n\nIn mm_cid_fixup_cpus_to_tasks(), when rq-\u003ecurr has the target mm and\nmm_cid.active is set, the CID is checked with cid_in_transit() before\nsetting the transition bit. In per-CPU mode a newly forked or exec\u0027d\ntask can be running with mm_cid.cid == MM_CID_UNSET because CIDs are\nassigned lazily on schedule-in. With cid_in_transit() the guard passes\nfor MM_CID_UNSET (no transit bit), converts it to MM_CID_UNSET |\nMM_CID_TRANSIT and stores it back; later mm_cid_schedout() feeds this\nto clear_bit() with MM_CID_UNSET as the bit number, triggering an\nout-of-bounds write.\n\nSymptoms: this is genuine memory corruption, but a bounded out-of-bounds\nwrite, not an arbitrary one. MM_CID_UNSET is the fixed sentinel BIT(31),\nso once the bad value reaches mm_cid_schedout() the cid_from_transit_cid()\nstrip leaves MM_CID_UNSET, which fails the \"cid \u003c max_cids\" convergence\ntest and falls into mm_drop_cid() -\u003e clear_bit(MM_CID_UNSET,\nmm_cidmask(mm)). The cid bitmap is embedded in the mm_struct slab object\n(after cpu_bitmap and mm_cpus_allowed) and is only num_possible_cpus()\nbits wide, so clearing bit 31 is a deterministic OOB bit-clear at a\nfixed offset of 2^31 / 8 == 256 MiB past the bitmap base. The address is\nnot attacker-influenced (fixed sentinel -\u003e fixed offset) and the op only\nclears a single bit; what sits 256 MiB further along the direct map is\nwhatever kernel object happens to live there, so this corrupts one bit of\nunpredictable kernel memory -- it is not an arbitrary-address or\narbitrary-value write.\n\nIt triggers only in per-CPU CID mode, when a CPU is running an active\ntask of the target mm whose cid is still MM_CID_UNSET -- the\nfork()/execve() window before that task\u0027s next schedule-in assigns it a\nreal CID -- and a per-CPU -\u003e per-task fixup walks over it (the mode\nfallback driven by a thread exit, sched_mm_cid_exit(), or by the deferred\nmax_cids recompute in mm_cid_work_fn()).\n\nIn practice syzkaller surfaced it as a KASAN use-after-free reported in\n__schedule -\u003e mm_cid_switch_to, where the offending clear_bit() is inlined\nvia mm_cid_schedout() -\u003e mm_drop_cid().\n\nGuard the transition-bit assignment against MM_CID_UNSET, in addition to\nthe existing cid_in_transit() check, so the bit is only set on a genuine\ntask-owned CID. A CPU-owned (MM_CID_ONCPU) CID of a running active task\nis handled by the cid_on_cpu(pcp-\u003ecid) branch above and never reaches\nthis path, so excluding MM_CID_UNSET (and the already-transitioning case)\nis sufficient.",
"id": "GHSA-2w6g-3pwr-88wc",
"modified": "2026-07-20T15:31:46Z",
"published": "2026-07-19T12:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63799"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8d32856fb72ba976d9c87ba405fd17e80419934c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de3ab9bd3133899efb92e4cd05ba4203e58fc0a3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.