CVE-2026-63799: sched/mmcid: Fix OOB clear_bit when CID is MM_CID_UNSET in fixup path

In the Linux kernel, the following vulnerability has been resolved:

sched/mmcid: Fix OOB clearbit when CID is MMCIDUNSET in fixup path

In mmcidfixupcpustotasks(), when rq->curr has the target mm and mmcid.active is set, the CID is checked with cidintransit() before setting the transition bit. In per-CPU mode a newly forked or exec'd task can be running with mmcid.cid == MMCIDUNSET because CIDs are assigned lazily on schedule-in. With cidintransit() the guard passes for MMCIDUNSET (no transit bit), converts it to MMCIDUNSET | MMCIDTRANSIT and stores it back; later mmcidschedout() feeds this to clearbit() with MMCIDUNSET 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. MMCIDUNSET is the fixed sentinel BIT(31), so once the bad value reaches mmcidschedout() the cidfromtransitcid() strip leaves MMCIDUNSET, which fails the "cid < maxcids" convergence test and falls into mmdropcid() -> clearbit(MMCIDUNSET, mmcidmask(mm)). The cid bitmap is embedded in the mmstruct slab object (after cpubitmap and mmcpusallowed) and is only numpossiblecpus() 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 MMCIDUNSET -- 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, schedmmcidexit(), or by the deferred maxcids recompute in mmcidworkfn()).

In practice syzkaller surfaced it as a KASAN use-after-free reported in schedule -> mmcidswitchto, where the offending clearbit() is inlined via mmcidschedout() -> mmdropcid().

Guard the transition-bit assignment against MMCIDUNSET, in addition to the existing cidintransit() check, so the bit is only set on a genuine task-owned CID. A CPU-owned (MMCIDONCPU) CID of a running active task is handled by the cidoncpu(pcp->cid) branch above and never reaches this path, so excluding MMCIDUNSET (and the already-transitioning case) is sufficient.