{"id":"CVE-2026-98385","state":"PUBLISHED","title":"sched/cache: Decouple sched_cache_group from mm to fix UAF","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched/cache: Decouple sched_cache_group from mm to fix UAF\n\nCurrently the sched cache grouping is by mm and the scheduling statistics\nsched_cache_stat lives in the mm structure.  This ties the life cycle\nof scheduling stats with mm.\n\nIn account_mm_sched(), the scheduling stats are accessed by\ntask->mm->sc_stat.  However, a task may be switching mm on one CPU when\nanother CPU is running account_mm_sched(), and possibly accessing the\nold mm that was freed.  This problem was found when running tests with\nKASAN by Hyunwoo:\n\n  https://lore.kernel.org/lkml/apPb-Dr4nPYuHQOK@v4bel/\n\nInstead of serializing the mm access by introducing extra acquisition of\nrq lock in the mm free path, extract sched_cache_stat from mm_struct,\nrename it as sched_cache_group and manage its life cycle apart from\nmm_struct with its own ref counting.  This allows us in the next patch\naccess sched_cache_group directly from task, and add a refcount\non sched_cache_group when a task links to it. This prevents the use\nafter free issue when accessing stale and released old mm and its\nsched cache stat a task switches to a new mm while account_mm_sched()\nis done elsewhere.\n\nThe other benefit of this restructure is in the future, the grouping of\ntasks to a LLC would have the flexibility to be associated with a user\ndefined grouping, or cgroup, cookie group, numa_group or others instead\nof just with a single mm address space.\n\nRename sched_cache_stat to sched_cache_group and turn it into a refcounted\nobject allocated from mm_struct.  The mm_struct now holds a pointer\n(sched_cache_grp) to this object instead of embedding it.","publishedAt":"2026-10-12T05:48:52.248Z","updatedAt":"2026-10-24T14:08:42.034Z","severity":{"score":7.8,"label":"High","version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","source":"Linux"},"assigner":"Linux","products":["Linux Linux"],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"df0d98475954d655571979aa061ecb07d7e00392","status":"affected","lessThan":"852ecb6bc0bc0106f44f74ba3944524732486025","versionType":"git"},{"version":"df0d98475954d655571979aa061ecb07d7e00392","status":"affected","lessThan":"28f9c0e0a0b94c5d3e1b634db545f6e1f94858c5","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["include/linux/mm_types.h","include/linux/sched.h","kernel/exit.c","kernel/sched/fair.c"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"7.2","status":"affected"},{"version":"0","status":"unaffected","lessThan":"7.2","versionType":"semver"},{"version":"7.2.9","status":"unaffected","lessThanOrEqual":"7.2.*","versionType":"semver"},{"version":"7.3","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["include/linux/mm_types.h","include/linux/sched.h","kernel/exit.c","kernel/sched/fair.c"]}],"references":["https://git.kernel.org/stable/c/852ecb6bc0bc0106f44f74ba3944524732486025","https://git.kernel.org/stable/c/28f9c0e0a0b94c5d3e1b634db545f6e1f94858c5"],"weaknesses":[],"ingestedAt":"2026-10-29T20:13:43.249Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2026/98xxx/CVE-2026-98385.json","commit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-98385","state":"PUBLISHED","datePublished":"2026-10-12T05:48:52.248Z","dateUpdated":"2026-10-24T14:08:42.034Z","assignerShortName":"Linux","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateReserved":"2026-09-25T10:25:14.345Z"},"containers":{"cna":{"title":"sched/cache: Decouple sched_cache_group from mm to fix UAF","descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nsched/cache: Decouple sched_cache_group from mm to fix UAF\n\nCurrently the sched cache grouping is by mm and the scheduling statistics\nsched_cache_stat lives in the mm structure.  This ties the life cycle\nof scheduling stats with mm.\n\nIn account_mm_sched(), the scheduling stats are accessed by\ntask->mm->sc_stat.  However, a task may be switching mm on one CPU when\nanother CPU is running account_mm_sched(), and possibly accessing the\nold mm that was freed.  This problem was found when running tests with\nKASAN by Hyunwoo:\n\n  https://lore.kernel.org/lkml/apPb-Dr4nPYuHQOK@v4bel/\n\nInstead of serializing the mm access by introducing extra acquisition of\nrq lock in the mm free path, extract sched_cache_stat from mm_struct,\nrename it as sched_cache_group and manage its life cycle apart from\nmm_struct with its own ref counting.  This allows us in the next patch\naccess sched_cache_group directly from task, and add a refcount\non sched_cache_group when a task links to it. This prevents the use\nafter free issue when accessing stale and released old mm and its\nsched cache stat a task switches to a new mm while account_mm_sched()\nis done elsewhere.\n\nThe other benefit of this restructure is in the future, the grouping of\ntasks to a LLC would have the flexibility to be associated with a user\ndefined grouping, or cgroup, cookie group, numa_group or others instead\nof just with a single mm address space.\n\nRename sched_cache_stat to sched_cache_group and turn it into a refcounted\nobject allocated from mm_struct.  The mm_struct now holds a pointer\n(sched_cache_grp) to this object instead of embedding it."}],"affected":[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","versions":[{"version":"df0d98475954d655571979aa061ecb07d7e00392","status":"affected","lessThan":"852ecb6bc0bc0106f44f74ba3944524732486025","versionType":"git"},{"version":"df0d98475954d655571979aa061ecb07d7e00392","status":"affected","lessThan":"28f9c0e0a0b94c5d3e1b634db545f6e1f94858c5","versionType":"git"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["include/linux/mm_types.h","include/linux/sched.h","kernel/exit.c","kernel/sched/fair.c"]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","versions":[{"version":"7.2","status":"affected"},{"version":"0","status":"unaffected","lessThan":"7.2","versionType":"semver"},{"version":"7.2.9","status":"unaffected","lessThanOrEqual":"7.2.*","versionType":"semver"},{"version":"7.3","status":"unaffected","lessThanOrEqual":"*","versionType":"original_commit_for_fix"}],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["include/linux/mm_types.h","include/linux/sched.h","kernel/exit.c","kernel/sched/fair.c"]}],"references":[{"url":"https://git.kernel.org/stable/c/852ecb6bc0bc0106f44f74ba3944524732486025"},{"url":"https://git.kernel.org/stable/c/28f9c0e0a0b94c5d3e1b634db545f6e1f94858c5"}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - An unprivileged local write(2) to an attacker-created pipe reaches anon_pipe_write()->try_to_wake_up()->ttwu_queue()->enqueue_task_fair()->update_curr()->update_se()->account_mm_sched(), while the attacker's execveat(2) frees rq->curr's old mm. No protocol supplies the trigger.\nAC:L - On a qualifying multi-LLC SMP host, CONFIG_SCHED_CACHE and sysctl_sched_cache_user both default enabled. The attacker controls both race sides by repeatedly waking or updating its queued task and execveat()ing its pinned trampoline, and can groom the freed per-CPU slot.\nPR:L - user_check_sched_setscheduler() permits the same-owner SCHED_IDLE/lower-priority sched_setattr() used to force update_curr() without CAP_SYS_NICE; pipe creation, permitted CPU affinity, and execveat() of the attacker's memfd also require no capability.\nUI:N - The attacker creates the pipe and tasks, drives sched_setattr() or write(), and calls execveat() to replace and release its own mm; no other user must mount, open, or approve anything.\nS:U - account_mm_sched() and mm_destroy_sched() are host-kernel scheduler/mm code, and the demonstrated result is UID-0 execution under that same kernel authority, not a guest-to-host or IOMMU boundary crossing.\nC:H - After mm_destroy_sched() frees sc_stat.pcpu_sched, __update_mm_sched() accesses its reclaimed epoch and runtime. The demonstrated reclaim corrupts a futex reference and reaches UID 0 through pipe/page-cache manipulation, enabling unrestricted data reads.\nI:H - The stale pcpu_sched->epoch write changes a reclaimed futex per-CPU reference from 1 to 0; the demonstrated follow-on UAF decrements pipe_buffer.flags, enables page-cache overwrite of /usr/bin/newgrp, and executes as UID 0.\nA:H - __update_mm_sched() and pcpu_sched->runtime += delta_exec access freed per-CPU storage; if reclamation is not steered, these writes can corrupt reused kernel objects and cause an oops or panic."}]}],"providerMetadata":{"shortName":"Linux","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","dateUpdated":"2026-10-24T14:08:42.034Z"},"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"7.2","versionEndExcluding":"7.2.9"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"7.2","versionEndExcluding":"7.3"}]}]}],"x_generator":{"engine":"bippy-1.2.0"}}}}}