{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-63799","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2026-07-19T07:54:57.013Z","datePublished":"2026-07-19T12:02:06.341Z","dateUpdated":"2026-08-17T04:51:04.486Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-17T04:51:04.486Z"},"descriptions":[{"lang":"en","value":"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->curr 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'd\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 < max_cids\" convergence\ntest and falls into mm_drop_cid() -> 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 -> 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's next schedule-in assigns it a\nreal CID -- and a per-CPU -> 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 -> mm_cid_switch_to, where the offending clear_bit() is inlined\nvia mm_cid_schedout() -> 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->cid) branch above and never reaches\nthis path, so excluding MM_CID_UNSET (and the already-transitioning case)\nis sufficient."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - The bug is reached only through local scheduler paths triggered by fork/clone, exit, and execve syscalls, not by any network, Bluetooth, or physical device interface.\nAC:L - An unprivileged attacker can deliberately create many threads to enter per-CPU CID mode, fork/exec a task that remains active with MM_CID_UNSET, and time thread exits or affinity-driven fixups to hit the vulnerable branch without depending on conditions outside their control.\nPR:L - Triggering the vulnerable fixup requires only standard unprivileged process operations (creating threads, forking, exiting) within one's own address space, including from unprivileged user namespaces.\nUI:N - Exploitation requires no action from any other user or administrator; the attacker drives the entire thread lifecycle and timing themselves.\nS:U - Impact is kernel memory corruption within the same kernel security boundary; it does not constitute a VM escape, sandbox breakout, or cross-authority boundary crossing.\nC:H - The out-of-bounds bit-clear corrupts unpredictable kernel memory at a fixed large offset, and any such memory corruption can potentially be leveraged for information disclosure even though the immediate primitive is a single-bit write.\nI:H - The vulnerability performs an out-of-bounds write via clear_bit() with bit number MM_CID_UNSET (BIT(31)), which is genuine kernel memory corruption in the integrity domain.\nA:H - Syzkaller reported this as a KASAN fault in __schedule -> mm_cid_switch_to, and corrupting arbitrary kernel memory can cause kernel oops, panic, or crash-level denial of service."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["kernel/sched/core.c"],"versions":[{"version":"fbd0e71dc370af73f6b316e4de9eed273dd90340","lessThan":"8d32856fb72ba976d9c87ba405fd17e80419934c","status":"affected","versionType":"git"},{"version":"fbd0e71dc370af73f6b316e4de9eed273dd90340","lessThan":"de3ab9bd3133899efb92e4cd05ba4203e58fc0a3","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["kernel/sched/core.c"],"versions":[{"version":"6.19","status":"affected"},{"version":"0","lessThan":"6.19","status":"unaffected","versionType":"semver"},{"version":"7.1.3","lessThanOrEqual":"7.1.*","status":"unaffected","versionType":"semver"},{"version":"7.2","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.19","versionEndExcluding":"7.1.3"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.19","versionEndExcluding":"7.2"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/8d32856fb72ba976d9c87ba405fd17e80419934c"},{"url":"https://git.kernel.org/stable/c/de3ab9bd3133899efb92e4cd05ba4203e58fc0a3"}],"title":"sched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path","x_generator":{"engine":"bippy-1.2.0"}}}}