Bug 2549480 (CVE-2026-98385)

Summary: CVE-2026-98385 kernel: sched/cache: Decouple sched_cache_group from mm to fix UAF
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: akhatavk, akito5623, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel. A race condition when switching memory management contexts allows the process scheduler to access memory that has already been freed, leading to a use-after-free condition. A local attacker could exploit this vulnerability to cause a Denial of Service (DoS) by crashing the system or potentially execute arbitrary code.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-10-12 06:11:24 UTC
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.

Comment 3 Akiyoshi Kurita 2026-10-17 03:25:00 UTC
A public local privilege escalation exploit has been reported for CVE-2026-98385 (Scheduler/mm_struct use-after-free).

The researcher reports successful root privilege escalation on Linux.

PoC and technical details:
https://github.com/V4bel/InfinityCore

Could Red Hat please confirm whether the affected scheduler configuration is enabled in RHEL 8, 9, or 10 kernels, and whether the relevant fixes have been backported?

Please also confirm the status of kernel-rt where applicable.

Given the reported working exploit, please consider whether the severity assessment requires an update.

Best regards,
Akiyoshi Kurita
Fedora / EPEL / AlmaLinux Contributor
Linux Kernel Developer