CVE-2026-43326

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel sched_ext scheduler path. When SCX_KICK_WAIT is processed from hard interrupt context, the kernel can busy-wait for another CPU's kick_sync value to advance while the waiting CPU is unable to reschedule and advance its own state. If two or more CPUs enter a cyclic wait condition, they can deadlock, causing CPU lockups and potentially making the host unresponsive. The impact is availability only; the described flaw does not provide confidentiality or integrity compromise by itself.

Why it matters to the business

A local user or process with the ability to exercise the affected sched_ext behavior could cause a Linux system to hang or become unavailable, disrupting workloads, containers, virtual machines, batch jobs, or infrastructure services running on the affected host. The vulnerability is not currently listed in CISA KEV, has no known ransomware association, and has a very low EPSS score, so broad internet-scale exploitation is unlikely; however, availability-sensitive systems and multi-tenant Linux hosts should still prioritize kernel updates because exploitation can result in full host disruption.

How an attack unfolds

An attacker first needs local execution on an affected Linux system and sufficient ability to trigger workloads that interact with the sched_ext scheduling path. The attacker then induces conditions where SCX_KICK_WAIT causes one CPU to wait for another CPU's kick_sync state while running in hardirq context. By causing multiple CPUs to enter interdependent waits, the attacker can create a wait cycle where none of the involved CPUs can progress. Because the waiting happens in a context that cannot reschedule normally, the affected CPUs may deadlock, leading to kernel soft lockups, hung tasks, or a fully unresponsive system that requires reboot or failover.

How to fix it

Upgrade the Linux kernel to a vendor-supplied version that includes the sched_ext fix for this issue. Because no exact fixed package versions were provided in the input, use the relevant distribution or kernel vendor advisory to identify the corrected kernel release for each affected platform. After updating, reboot into the fixed kernel and ensure the old vulnerable kernel is not still the active boot target. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workload execution, disabling or avoiding sched_ext functionality where feasible, and using workload isolation or host-level failover for critical services. Mitigations should be treated as temporary because the reliable fix is the corrected kernel behavior that defers the wait out of hardirq context.

How to confirm the fix worked

Confirm the active running kernel has been upgraded to a vendor build containing the fix, not merely installed on disk. Validate with standard host commands such as `uname -a`, package manager kernel version checks, and distribution security advisory mappings. Review bootloader configuration to ensure systems will continue booting into the fixed kernel after restart. Where sched_ext is used, perform controlled stress or scheduler validation testing in a non-production environment and confirm the system does not produce CPU lockup, hung task, RCU stall, or scheduler deadlock warnings. Vulnerability scanners should be configured to identify affected Linux kernel versions and verify remediation based on the running kernel version.

Typical attack path

1. Gain local code execution or access to run workloads on an affected Linux host.
2. Determine that the system is running an affected kernel with sched_ext support enabled or available.
3. Run a workload designed to exercise sched_ext CPU kick and wait behavior across multiple CPUs.
4. Trigger cyclic SCX_KICK_WAIT conditions where CPUs wait on each other's kick_sync progress.
5. Cause CPU deadlock, kernel lockup symptoms, service outage, or full host unresponsiveness.

How to detect it

To determine whether this was already exploited, review host telemetry and kernel logs for signs of unexplained CPU deadlock or scheduler-related lockups, especially on systems where untrusted users or workloads can run locally. Useful sources include `dmesg`, journald kernel logs, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump records, watchdog alerts, hypervisor reset events, EDR process history, shell command logs, job scheduler logs, container runtime logs, and audit logs showing local workload execution before a hang or reboot. Look for bursts of CPU-intensive local processes followed by kernel messages such as soft lockups, hard lockups, RCU stalls, hung tasks, NMI watchdog alerts, or sched_ext/scx references. Because this vulnerability primarily causes availability failure rather than leaving a durable payload, detection is circumstantial: correlate lockup timestamps with user sessions, newly launched binaries, container jobs, batch jobs, or repeated host resets. Absence of persistent files or network indicators does not rule out exploitation.

• sched_ext
• SCX_KICK_WAIT
• kick_cpus_irq_workfn
• do_pick_task_scx
• kick_sync
• BUG: soft lockup
• BUG: hard lockup
• NMI watchdog: Watchdog detected hard LOCKUP
• watchdog: BUG: soft lockup
• rcu: INFO: rcu_sched self-detected stall
• rcu: INFO: rcu_preempt self-detected stall
• INFO: task
• blocked for more than
• hung_task
• kernel: sched_ext
• kernel: scx
• kernel: BUG: soft lockup
• kernel: BUG: hard lockup
• kernel: NMI watchdog
• kernel: rcu: INFO
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux systems running kernels with sched_ext support and prioritize availability-critical, multi-tenant, CI/CD, container, virtualization, and high-density compute hosts.
• Apply vendor kernel updates that include the fix, then reboot systems into the corrected kernel.
• If patching is delayed, restrict local access and untrusted workload execution on affected hosts, especially where users can run CPU-intensive or scheduler-interacting workloads.
• Monitor affected systems for kernel lockup, RCU stall, hung task, scheduler, and NMI watchdog messages that may indicate attempted or successful denial-of-service activity.
• Ensure operational recovery plans are in place for affected systems, including remote power control, automated failover, and safe reboot procedures.
• Track vendor advisories for exact fixed kernel versions because the input did not provide per-package fixed versions.