CVE-2026-23225: sched/mmcid: Don't assume CID is CPU owned on mode switch
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().
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel memory-safety flaw in scheduler MMCID handling. A low-privileged local user could potentially trigger kernel memory corruption, affecting confidentiality, integrity, and availability. The issue is high severity, but the provided sources do not show active exploitation.
Executive priority
Treat as high priority for Linux fleets with local users, shared compute, or untrusted workloads. Patch through normal kernel update channels promptly, but do not assume internet-facing remote exploitation from the provided evidence.
Technical view
The bug occurs during MMCID mode switching when TRANSIT is set but ONCPU is not. sched_mm_cid_exit() incorrectly assumes CPU ownership and calls mm_drop_cid_on_cpu(), leading to an out-of-bounds bit operation. The fix validates CPU ownership before dropping the CID.
Likely exposure
Exposure is limited to systems running affected Linux kernel versions identified in the CVE data. Risk is highest on shared Linux systems or hosts where untrusted local users or workloads can execute code.
Exploitation context
The CVSS vector is local, low complexity, low privilege, and no user interaction. CISA KEV status is false in the bundle, and no cited source claims active exploitation.
Researcher notes
The source describes a KASAN-reported out-of-bounds access related to MMCID TRANSIT and ONCPU state handling. Affected-version evidence in the bundle is limited and should be cross-checked against vendor kernel branches and the two upstream stable commits.
Mitigation direction
Check Linux vendor or distribution advisories for patched kernel packages.
Apply kernel updates containing the referenced stable fixes.
Prioritize shared systems and hosts running untrusted workloads.
Restrict untrusted local shell or workload access where patching is delayed.
Validation and detection
Inventory running Linux kernel versions across affected environments.
Compare kernel versions against CVE and vendor advisory affected ranges.
Confirm whether referenced stable commits are present in deployed kernels.
Track CISA KEV and vendor advisories for exploitation or mitigation updates.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23225 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.