CVE-2026-98866: sched/cache: Introduce task_struct->sched_cache_grp to fix UAF
In the Linux kernel, the following vulnerability has been resolved:
sched/cache: Introduce taskstruct->schedcachegrp to fix UAF
Add a schedcachegrp pointer to taskstruct so that scheduler code can access the cache group directly via the task, without going through mm->schedcachegrp. This decouples the scheduler's hot-path accesses from the mmstruct.
Each task holds its own refcount on the schedcachegroup, separate from the reference held by its mmstruct. The reference is acquired in copymm() (fork) and execmmap() (exec), and released in exitmm(). This fixes the use-after-free when accountmmsched() 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->schedcachegrp instead of p->mm->schedcachegrp.
Keep the fork/exec/exit reference management out of the generic mm paths: add schedcachefork(), schedcacheforkcleanup(), schedcacheexecmmap() and schedcacheexitmm() in kernel/sched/cachesched.c (with empty stubs for !CONFIGSCHEDCACHE), 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 schedcachegroupget() and taskcachegroupget().
Affected Software
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The issue concerns Linux kernel scheduler cache-group handling. The provided data indicates that sched-cache support is relevant, as the fix includes stubs when CONFIG_SCHED_CACHE is not enabled, but it does not identify specific affected kernel versions or distributions.
When can the use-after-free occur?
It can occur when account_mm_sched() accesses a scheduler cache group through a task while that task's mm structure is being switched. The unsafe path was reaching the group through p->mm->sched_cache_grp.
What changes in the fix?
The fix gives each task its own sched_cache_grp pointer and reference count, so scheduler code accesses p->sched_cache_grp directly rather than going through the task's mm structure. References are acquired during fork and exec-related mm setup and released during exit-mm handling.
How can I verify that a fix is present?
The provided references identify stable kernel commits 9436130e6da72af63289a4acb3aa0c1df07a3928 and b636fef85bda7d1bab9c0a45067ab1508d79d946. A fixed source tree will use p->sched_cache_grp in the relevant scheduler code and include the sched_cache fork, exec, and exit helper handling described.