CVE-2026-23225

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

sched/mmcid: Don't assume CID is CPU owned on mode switch

Shinichiro reported a KASAN UAF, which is actually an out of bounds access

in the MMCID management code.

CPU0 CPU1

T1 runs in userspace

T0: fork(T4) -> Switch to per CPU CID mode

fixup() set MM_CID_TRANSIT on T1/CPU1

T4 exit()

T3 exit()

T2 exit()

T1 exit() switch to per task mode

---> Out of bounds access.

As T1 has not scheduled after T0 set the TRANSIT bit, it exits with the

TRANSIT bit set. sched_mm_cid_remove_user() clears the TRANSIT bit in

the task and drops the CID, but it does not touch the per CPU storage.

That's functionally correct because a CID is only owned by the CPU when

the ONCPU bit is set, which is mutually exclusive with the TRANSIT flag.

Now sched_mm_cid_exit() assumes that the CID is CPU owned because the

prior mode was per CPU. It invokes mm_drop_cid_on_cpu() which clears the

not set ONCPU bit and then invokes clear_bit() with an insanely large

bit number because TRANSIT is set (bit 29).

Prevent that by actually validating that the CID is CPU owned in

mm_drop_cid_on_cpu().