CVE-2026-43326 Overview
CVE-2026-43326 is a deadlock vulnerability in the Linux kernel's sched_ext (extensible scheduler) subsystem. The flaw resides in the SCX_KICK_WAIT mechanism, where kick_cpus_irq_workfn() performs a busy-wait using smp_cond_load_acquire() in hardirq context. Because the waiting CPU cannot reschedule while in hardirq, its own kick_sync counter never advances. When multiple CPUs form a cyclic wait dependency, all participating CPUs deadlock, leading to a system hang and denial of service. The vulnerability affects Linux kernel 7.0 release candidates rc1 through rc7 and is tracked under [CWE-667: Improper Locking].
Critical Impact
A local, low-privileged user on a system running an affected sched_ext scheduler can trigger a multi-CPU deadlock, resulting in a complete system hang and high availability impact.
Affected Products
- Linux Kernel 7.0-rc1 through 7.0-rc7
- Systems using the sched_ext BPF scheduler framework
- Distributions shipping pre-release 7.0 kernels with SCX enabled
Discovery Timeline
- 2026-05-08 - CVE-2026-43326 published to NVD
- 2026-05-15 - Last updated in NVD database
Technical Details for CVE-2026-43326
Vulnerability Analysis
The sched_ext subsystem allows BPF programs to implement custom CPU schedulers. The SCX_KICK_WAIT flag instructs a CPU to kick another CPU and synchronously wait for the target's scheduler state to advance before continuing. This synchronization is implemented in kick_cpus_irq_workfn(), which runs inside an irq_work handler executing in hardirq context.
The handler invokes smp_cond_load_acquire() to busy-poll the target CPU's kick_sync value. Because hardirq context disables preemption and prevents the waiting CPU from rescheduling, the waiting CPU cannot itself enter do_pick_task_scx() to advance its own kick_sync. When CPU A waits for CPU B while CPU B (or a chain ending in CPU A) is simultaneously waiting back, no CPU in the cycle can make forward progress.
Root Cause
The root cause is performing a synchronous cross-CPU wait inside hardirq context without a path for the waiting CPU to service incoming IPIs or advance scheduler state. The design violates the invariant that hardirq handlers must not block on conditions requiring action by the local CPU's scheduler.
Attack Vector
Exploitation requires local access with the ability to load or interact with a sched_ext BPF scheduler that issues SCX_KICK_WAIT kicks in patterns producing cyclic wait dependencies. A malicious or buggy BPF scheduler program can deterministically construct such cycles, hanging the affected CPUs and degrading or halting the system.
The upstream fix replaces the busy-wait in kick_cpus_irq_workfn() with a resched_curr() call, forcing the CPU through do_pick_task_scx(). That path queues a balance callback that drops the runqueue lock and re-enables IRQs (following the sched_core_balance() pattern), allowing IPI processing during the wait. The local CPU's kick_sync is advanced on entry and throughout the wait, breaking any potential cyclic dependency. See the patch commits Kernel Git Commit 415cb19 and Kernel Git Commit c3a7903 for implementation details.
Detection Methods for CVE-2026-43326
Indicators of Compromise
- Multiple CPUs reporting hardlockup warnings or RCU stall messages referencing kick_cpus_irq_workfn or smp_cond_load_acquire in stack traces.
- Kernel soft/hard lockup logs naming the sched_ext subsystem with stuck CPUs in irq_work_run.
- System hangs or unresponsive CPUs following the load of a custom sched_ext BPF scheduler.
Detection Strategies
- Audit loaded BPF programs of type BPF_PROG_TYPE_STRUCT_OPS attached to sched_ext to identify custom schedulers in use.
- Monitor kernel ring buffer (dmesg) for watchdog: BUG: soft lockup or rcu_sched detected stalls traces involving SCX functions.
- Track kernel version with uname -r and flag systems running 7.0-rc1 through 7.0-rc7 with CONFIG_SCHED_CLASS_EXT=y.
Monitoring Recommendations
- Enable softlockup_panic and hardlockup_panic in test environments to surface the deadlock condition during validation.
- Forward kernel logs to a central SIEM and alert on lockup signatures referencing sched_ext or kick_cpus_irq_workfn.
- Track BPF program load events via bpf LSM hooks or audit subsystem to detect deployment of custom schedulers on production hosts.
How to Mitigate CVE-2026-43326
Immediate Actions Required
- Apply the upstream kernel patches referenced in commits 415cb193bb97 and c3a7903f65cf and rebuild affected kernels.
- Upgrade from Linux 7.0 release candidate kernels to a stable release that incorporates the fix.
- Restrict the CAP_BPF and CAP_SYS_ADMIN capabilities to limit which users can load sched_ext BPF schedulers.
Patch Information
The fix is committed upstream in Kernel Git Commit 415cb19 and Kernel Git Commit c3a7903. The patch replaces the hardirq-context busy-wait with a deferred wait executed by a balance callback, allowing the waiting CPU to drop the runqueue lock, re-enable IRQs, and advance its own kick_sync value.
Workarounds
- Disable sched_ext by booting with CONFIG_SCHED_CLASS_EXT=n or by not loading custom BPF schedulers until the patched kernel is deployed.
- Detach any active SCX scheduler using bpftool struct_ops unregister to fall back to the default CFS/EEVDF scheduler.
- Block unprivileged BPF program loading by setting kernel.unprivileged_bpf_disabled=1 via sysctl.
# Configuration example
# Disable unprivileged BPF and verify sched_ext status
sudo sysctl -w kernel.unprivileged_bpf_disabled=1
echo 'kernel.unprivileged_bpf_disabled=1' | sudo tee -a /etc/sysctl.d/99-bpf.conf
# Check for active sched_ext schedulers
cat /sys/kernel/sched_ext/state
sudo bpftool struct_ops list
# Detach an active SCX scheduler if needed
sudo bpftool struct_ops unregister id <ID>
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
