CVE-2026-23225
Received Received - Intake
Out-of-Bounds Access in Linux Kernel MMCID Causes Potential Memory Corruption

Publication date: 2026-02-18

Last updated on: 2026-04-02

Assigner: kernel.org

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().
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-18
Last Modified
2026-04-02
Generated
2026-05-07
AI Q&A
2026-02-18
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is an out of bounds access issue in the Linux kernel's MMCID management code related to CPU and task mode switching.

Specifically, when a task (T1) switches modes without being scheduled after a previous task (T0) set a TRANSIT bit, the system incorrectly assumes that a CPU ID (CID) is owned by the CPU. This leads to an invalid operation where a very large bit number is cleared, causing an out of bounds access.

The root cause is that the code does not properly validate whether the CID is actually CPU owned before performing certain operations, which results in a use-after-free (UAF) type error detected by KASAN.


How can this vulnerability impact me? :

This vulnerability can lead to memory corruption due to out of bounds access in kernel memory management.

Such memory corruption could potentially cause system instability, crashes, or unpredictable behavior in the Linux kernel.

In some cases, memory corruption vulnerabilities in the kernel can be exploited to escalate privileges or execute arbitrary code, though this specific impact is not detailed in the provided information.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

I don't know


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart