Cloudanix VulnDB

CVE-2026-98866

None

CVSS

—

EPSS

0.1%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how the Linux kernel tracks scheduling information for processes could let an attacker on the same machine crash the system or gain elevated access.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Linux kernel scheduler when account_mm_sched() accesses sched_cache_grp via a task whose mm_struct is concurrently switched or freed during fork/exec/exit paths.

Why it matters to the business

Attackers can trigger kernel memory corruption leading to crashes, denial of service, or potential local privilege escalation on affected systems; the issue affects core process scheduling so widespread impact is possible on Linux servers and endpoints.

How an attack unfolds

An attacker with local access crafts a sequence of process creation, memory mapping changes, and scheduler accounting events that cause a reference to a freed sched_cache_group to be dereferenced through the stale mm pointer before the new per-task reference counting is in place.

How to fix it

Apply the kernel patch that adds task_struct->sched_cache_grp, introduces sched_cache_fork/exec/exit helpers, and converts all scheduler references in fair.c and exit.c to the per-task pointer; rebuild and reboot with the fixed kernel.

How to confirm the fix worked

Confirm the presence of sched_cache_grp in task_struct and the new cache_sched.c helpers; verify that mm->sched_cache_grp is no longer accessed from scheduler hot paths after the update.

Typical attack path

  1. Obtain local code execution on a Linux system
  2. Trigger fork or exec operations combined with mm switching
  3. Force scheduler fair.c or exit.c paths to dereference the freed group via mm
  4. Achieve memory corruption or crash for further exploitation

How to detect it

Review kernel logs for use-after-free warnings or oops in sched/fair.c and sched/exit.c around account_mm_sched; look for unusual patterns of process fork/exec/exit coinciding with scheduler accounting.

What your security team should do

  • Prioritize patching Linux kernels on all exposed systems within the next maintenance window
  • Monitor for related scheduler or mm_struct crashes in kernel logs
  • Limit untrusted local code execution until patches are deployed

The record

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().

Affected packages

Ecosystem Package Introduced Fixed