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 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().
Published: 2026-02-18
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: Kernel out-of-bounds access that can lead to privilege escalation
Action: Immediate Patch
AI Analysis

Impact

A bug in the Linux kernel scheduler occurs when it assumes a CPU‑owned CID during a mode switch, causing mm_drop_cid_on_cpu to clear a bit with an extremely large index. This results in an out-of-bounds write into per-CPU storage, which can corrupt kernel memory and provide a local attacker with the ability to gain elevated privileges or destabilize the system. The flaw represents a kernel-space use‑after‑free or buffer overflow weakness.

Affected Systems

Any Linux kernel build that contains the unpatched MMCID code is vulnerable. The advisory does not list specific releases, so all kernels prior to the commit that introduces the fix must be considered affected.

Risk and Exploitability

The CVSS score of 7.8 indicates high severity, while the EPSS score of less than 1% suggests a low likelihood of public exploitation at this time. The vulnerability resides in core scheduler logic, so exploitation would require local access to influence task scheduling or trigger the mode switch. The flaw is not currently listed in the CISA KEV catalog.

Generated by OpenCVE AI on April 15, 2026 at 15:48 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the MMCID fix from the referenced commit.
  • If an immediate kernel upgrade is not feasible, disable per‑CPU CID mode in the kernel configuration until the patch can be applied.
  • Inspect and remove or update any custom modules that modify or rely on task CIDs, ensuring they are compatible with the patched kernel.

Generated by OpenCVE AI on April 15, 2026 at 15:48 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 15 Apr 2026 17:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416
CWE-788

Thu, 02 Apr 2026 15:15:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

 cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Mon, 23 Feb 2026 03:30:00 +0000

Type Values Removed Values Added
References

Thu, 19 Feb 2026 00:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

 cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Important

Wed, 18 Feb 2026 15:30:00 +0000

Type Values Removed Values Added
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 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().
Title sched/mmcid: Don't assume CID is CPU owned on mode switch
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-04-13T06:02:40.890Z

Reserved: 2026-01-13T15:37:45.987Z

Link: CVE-2026-23225

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Deferred

Published: 2026-02-18T16:22:32.260

Modified: 2026-04-15T00:35:42.020

Link: CVE-2026-23225

cve-icon Redhat

Severity : Important

Publid Date: 2026-02-18T00:00:00Z

Links: CVE-2026-23225 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-04-15T17:30:10Z

Weaknesses