CVE-2026-23225

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/mmcid: Don&amp;#39;t assume CID is CPU owned on mode switch<br /> <br /> Shinichiro reported a KASAN UAF, which is actually an out of bounds access<br /> in the MMCID management code.<br /> <br /> CPU0 CPU1<br /> T1 runs in userspace<br /> T0: fork(T4) -&gt; Switch to per CPU CID mode<br /> fixup() set MM_CID_TRANSIT on T1/CPU1<br /> T4 exit()<br /> T3 exit()<br /> T2 exit()<br /> T1 exit() switch to per task mode<br /> ---&gt; Out of bounds access.<br /> <br /> As T1 has not scheduled after T0 set the TRANSIT bit, it exits with the<br /> TRANSIT bit set. sched_mm_cid_remove_user() clears the TRANSIT bit in<br /> the task and drops the CID, but it does not touch the per CPU storage.<br /> That&amp;#39;s functionally correct because a CID is only owned by the CPU when<br /> the ONCPU bit is set, which is mutually exclusive with the TRANSIT flag.<br /> <br /> Now sched_mm_cid_exit() assumes that the CID is CPU owned because the<br /> prior mode was per CPU. It invokes mm_drop_cid_on_cpu() which clears the<br /> not set ONCPU bit and then invokes clear_bit() with an insanely large<br /> bit number because TRANSIT is set (bit 29).<br /> <br /> Prevent that by actually validating that the CID is CPU owned in<br /> mm_drop_cid_on_cpu().