CVE-2026-98385
—UnscoredPublished 12 Oct 2026 · NVD status: Received · AI triage by gemini-3.8-flash
- Attack vector
- —
- Complexity
- —
- Privileges needed
- —
- User interaction
- —
- Impact
- —
- Weakness
- —
Impact
A local attacker can trigger a kernel crash or potentially execute arbitrary code with kernel privileges by exploiting a race condition during memory management switching. The attacker needs local access to run concurrent processes on the target system.
Root cause
A use-after-free race condition occurs when account_mm_sched() accesses scheduling cache statistics in an mm_struct that is simultaneously being freed during an mm switch on another CPU.
Affected systems
Versions not listed — check the vendor advisory.
Fix & remediation
Upgrade to a Linux kernel build containing commits 28f9c0e0a0b94c5d3e1b634db545f6e1f94858c5 or 852ecb6bc0bc0106f44f74ba3944524732486025. No interim configuration mitigation is available.
$ uname -rAI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
In the Linux kernel, the following vulnerability has been resolved: sched/cache: Decouple sched_cache_group from mm to fix UAF Currently the sched cache grouping is by mm and the scheduling statistics sched_cache_stat lives in the mm structure. This ties the life cycle of scheduling stats with mm. In account_mm_sched(), the scheduling stats are accessed by task->mm->sc_stat. However, a task may be switching mm on one CPU when another CPU is running account_mm_sched(), and possibly accessing the old mm that was freed. This problem was found when running tests with KASAN by Hyunwoo: https://lore.kernel.org/lkml/apPb-Dr4nPYuHQOK@v4bel/ Instead of serializing the mm access by introducing extra acquisition of rq lock in the mm free path, extract sched_cache_stat from mm_struct, rename it as sched_cache_group and manage its life cycle apart from mm_struct with its own ref counting. This allows us in the next patch access sched_cache_group directly from task, and add a refcount on sched_cache_group when a task links to it. This prevents the use after free issue when accessing stale and released old mm and its sched cache stat a task switches to a new mm while account_mm_sched() is done elsewhere. The other benefit of this restructure is in the future, the grouping of tasks to a LLC would have the flexibility to be associated with a user defined grouping, or cgroup, cookie group, numa_group or others instead of just with a single mm address space. Rename sched_cache_stat to sched_cache_group and turn it into a refcounted object allocated from mm_struct. The mm_struct now holds a pointer (sched_cache_grp) to this object instead of embedding it.