CVE-2026-23225

/// Technical description

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 O

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References