CVE-2026-46154

What it actually does

This is a local Linux kernel use-after-free in the sched_ext cgroup handling path. The vulnerable cgroup setter functions cache the global sched_ext scheduler pointer before taking the synchronization lock that protects cgroup scheduler operations. If one sched_ext scheduler is disabled and freed while another scheduler is enabled in the race window, the setter can observe the new enabled state while dereferencing the old freed scheduler pointer. Successful exploitation can corrupt kernel memory and may allow local privilege escalation, kernel code execution, information disclosure, or a system crash. Exploitation is high complexity because it requires precise racing of sched_ext enable/disable activity with cgroup CPU control writes, and the CVSS vector indicates local access with low privileges and no user interaction.

Why it matters to the business

A local user or compromised workload with access to relevant cgroup CPU controls could potentially escalate privileges or crash affected Linux systems, putting host isolation, workload availability, and sensitive data at risk. The issue is not known to be in CISA KEV, is not reported as used in ransomware campaigns, has low EPSS, and has no public exploit maturity in the provided data, but the impact is high because successful exploitation occurs in kernel space. Systems that use or expose sched_ext, delegated cgroup management, containers, or custom BPF-based schedulers should treat this as higher priority than systems where sched_ext is disabled or unavailable.

How an attack unfolds

An attacker first obtains local execution on an affected Linux host, such as through a shell, compromised service account, or container/workload with delegated cgroup control. They then identify whether sched_ext support is present and whether cgroup CPU controller files can be modified. The attacker repeatedly writes to sched_ext-related cgroup setters such as weight, idle, or bandwidth controls while concurrently causing sched_ext schedulers to be disabled, freed through RCU, and replaced by another scheduler. If the timing succeeds, the kernel uses a stale scheduler pointer after the old scheduler object has been freed. The resulting use-after-free may be shaped into a kernel crash or, with a more advanced exploit, controlled memory corruption for privilege escalation. There is no indication from the supplied intelligence that this flaw is currently being exploited in the wild, but kernel memory corruption bugs should still be remediated promptly where exposed.

How to fix it

Apply the Linux kernel vendor update that includes the sched_ext fix for this issue. No exact fixed kernel versions were provided in the input, so use distribution security advisories, package changelogs, or upstream stable kernel release notes to identify the first fixed build for each supported platform. Where immediate patching is not possible, reduce exposure by disabling or avoiding sched_ext, not loading custom sched_ext/BPF schedulers, restricting cgroup CPU controller delegation to trusted administrators, removing write access to cgroup CPU control files for untrusted users or containers, and enforcing least privilege around capabilities commonly needed for scheduler/BPF operations such as CAP_SYS_ADMIN, CAP_BPF, and CAP_PERFMON. Consider disabling unprivileged BPF where applicable and using mandatory access controls to limit writes under cgroup control paths.

How to confirm the fix worked

Confirm the installed kernel package includes the vendor backport or upstream patch that reads scx_root only while holding scx_cgroup_ops_rwsem in the sched_ext cgroup setter paths. Validate through package metadata, distribution advisory references, kernel changelogs, or source inspection of the relevant sched_ext code. Check whether the running kernel was rebooted into the fixed version, not merely installed on disk. Confirm whether sched_ext is compiled in and active by reviewing kernel configuration and runtime sched_ext state, such as CONFIG_SCHED_CLASS_EXT and sched_ext sysfs entries where present. Review cgroup filesystem permissions to ensure untrusted users and workloads cannot write CPU scheduling controls unless explicitly intended. In staging, reproduce exposure checks by verifying that cgroup CPU setter writes are either unavailable to untrusted principals or run on a fixed kernel without kernel warnings, KASAN findings, oopses, or crashes during sched_ext enable/disable testing.

Typical attack path

1. Gain local code execution on an affected Linux system.
2. Determine whether sched_ext is enabled or available and whether cgroup CPU controller writes are permitted.
3. Prepare concurrent activity that toggles sched_ext scheduler state, causing one scheduler instance to be disabled and freed while another is enabled.
4. Repeatedly write to cgroup CPU scheduling controls such as weight, idle, or bandwidth settings to enter the vulnerable setter paths.
5. Win the race so the setter dereferences a freed sched_ext scheduler pointer.
6. Use the resulting kernel memory corruption to crash the system or attempt local privilege escalation.

How to detect it

Retrospective detection should focus on local exploitation symptoms because a successful kernel use-after-free may leave few reliable application-level artifacts. Review kernel logs from journald, dmesg, syslog, crash dumps, kdump/vmcore, and hypervisor reset records for oopses, panics, KASAN reports, RCU warnings, and sched_ext/cgroup messages near unexpected reboots or privilege changes. Correlate with auditd, eBPF telemetry, shell history, process accounting, and EDR events for repeated writes to cgroup CPU control files and activity involving sched_ext scheduler load/unload operations. Investigate unusual use of bpftool, scheduler management utilities, direct writes under /sys/kernel/sched_ext, and high-rate modifications under /sys/fs/cgroup. On container hosts, review container runtime and orchestrator logs for workloads granted unusual cgroup, BPF, or administrative capabilities. Treat crashes containing scx_group_set_weight, scx_group_set_idle, scx_group_set_bandwidth, SCX_HAS_OP, SCX_CALL_OP, or sched_ext in the kernel stack as high-signal indicators requiring forensic review.

• BUG: KASAN: use-after-free
• use-after-free in scx_group_set_weight
• use-after-free in scx_group_set_idle
• use-after-free in scx_group_set_bandwidth
• scx_group_set_weight
• scx_group_set_idle
• scx_group_set_bandwidth
• SCX_HAS_OP
• SCX_CALL_OP
• sched_ext
• /sys/kernel/sched_ext
• /sys/fs/cgroup/cpu.weight
• /sys/fs/cgroup/cpu.idle
• /sys/fs/cgroup/cpu.max
• bpftool prog load
• bpftool struct_ops
• kernel NULL pointer dereference in sched_ext
• general protection fault in scx_group_set
• RCU detected stall
• kernel panic - not syncing

What your security team should do

• Inventory Linux systems running kernels with sched_ext support, especially hosts using custom sched_ext/BPF schedulers, container platforms, CI runners, and multi-tenant compute nodes.
• Prioritize patching systems where untrusted users or workloads can write cgroup CPU controller settings or where sched_ext is enabled in production.
• If a vendor patch is not yet available, disable sched_ext usage and restrict write permissions to cgroup CPU control files as a compensating control.
• Audit cgroup delegation policies for containers, user sessions, and service managers to ensure CPU controller writes are not unnecessarily exposed.
• Monitor kernel logs for use-after-free, KASAN, RCU, sched_ext, and cgroup-related crashes that may indicate attempted exploitation or instability.
• Harden local privilege-escalation paths by limiting administrative capabilities, disabling unprivileged BPF where feasible, and enforcing SELinux/AppArmor or equivalent controls.
• Because the issue is not KEV-listed, has low EPSS, and has no known exploit maturity in the supplied data, align emergency response to actual sched_ext exposure rather than treating all Linux systems equally.