CVE-2026-98385: sched/cache: Decouple sched_cache_group from mm to fix UAF
In the Linux kernel, the following vulnerability has been resolved:
sched/cache: Decouple schedcachegroup from mm to fix UAF
Currently the sched cache grouping is by mm and the scheduling statistics schedcachestat lives in the mm structure. This ties the life cycle of scheduling stats with mm.
In accountmmsched(), the scheduling stats are accessed by task->mm->scstat. However, a task may be switching mm on one CPU when another CPU is running accountmmsched(), 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 schedcachestat from mmstruct, rename it as schedcachegroup and manage its life cycle apart from mmstruct with its own ref counting. This allows us in the next patch access schedcachegroup directly from task, and add a refcount on schedcachegroup 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 accountmmsched() 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, numagroup or others instead of just with a single mm address space.
Rename schedcachestat to schedcachegroup and turn it into a refcounted object allocated from mmstruct. The mmstruct now holds a pointer (schedcachegrp) to this object instead of embedding it.
Affected Software
Event History
Frequently Asked Questions
What race condition triggers the use-after-free?
The issue can occur when one CPU switches a task to a different memory-management context while another CPU runs account_mm_sched() and accesses scheduling statistics through the task's old mm. If that old mm has already been freed, the access becomes a use-after-free.
Which systems or workloads are most likely to encounter this issue?
The affected code is in the Linux kernel scheduler cache-grouping logic. The race was identified during KASAN-enabled testing, but the description does not limit the condition to KASAN builds.
What change resolves the lifetime problem?
The fix separates the scheduling cache statistics from mm_struct, renames the object to sched_cache_group, and manages it with separate reference counting. Tasks hold a reference when linked to the group, preventing access to a stale freed mm through the scheduling-statistics path.