CVE-2026-98219

What it actually does

Race condition in sched_ext allows scx_bpf_error_bstr() error claim from BPF program to be consumed by scx_disable_workfn() before scx_root_enable_workfn() completes state transition, leaving scheduler enabled but undisableable and causing bpf_scx_unreg() to free in-use memory.

Why it matters to the business

Linux systems using sched_ext schedulers can experience kernel instability, crashes, or potential privilege escalation; the bug affects bleeding-edge scheduler deployments and raises patch urgency for environments relying on extended scheduling.

How an attack unfolds

An attacker loads or triggers a BPF program attached to sched_ext that invokes scx_bpf_error_bstr() during the brief pre-enable window; the resulting error path shortcut skips teardown, the enable workfn finishes, and later unregistration frees live scheduler structures leading to use-after-free.

How to fix it

Update to a kernel containing the fix that moves the SCX_ENABLING state transition before scheduler allocation so ops->priv is never visible while SCX_DISABLED; rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Confirm the kernel version contains the sched_ext state-ordering change; verify both WARN_ON_ONCE sites are absent after loading and erroring a sched_ext scheduler; run targeted enable/disable stress tests with error injection.

Typical attack path

1. Obtain local access or sufficient privileges to load BPF programs and interact with sched_ext
2. Trigger scx_alloc_and_add_sched() while racing an error claim via scx_bpf_error_bstr()
3. Force the pre-enable shortcut in scx_root_disable() to leave the scheduler in a broken enabled state
4. Trigger bpf_scx_unreg() to free still-in-use structures and trigger UAF

How to detect it

Search kernel logs for the two consecutive WARN_ON_ONCE messages referencing scx_root_enable_workfn and scx_root_disable; inspect audit logs for unusual BPF program loads or sched_ext enable attempts around the time of crashes.

What your security team should do

• Prioritize kernel upgrade for any hosts using sched_ext schedulers
• Disable sched_ext on systems where the feature is not required until patched
• Monitor kernel logs for the paired WARN_ON_ONCE messages indicating the race
• Restrict unprivileged BPF loading via sysctl or LSM policies