Skip to main content

Linux Kernel EUVDEUVD-2026-28610

| CVE-2026-43326 MEDIUM
Improper Locking (CWE-667)
2026-05-08 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-3vvp-54wc-f6jr
Linux Information Disclosure Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

4
Analysis Generated
May 15, 2026 - 18:07 vuln.today
CVSS changed
May 15, 2026 - 18:07 NVD
5.5 (MEDIUM)
Patch available
May 08, 2026 - 15:02 EUVD
CVE Published
May 08, 2026 - 14:16 nvd
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

sched_ext: Fix SCX_KICK_WAIT deadlock by deferring wait to balance callback

SCX_KICK_WAIT busy-waits in kick_cpus_irq_workfn() using smp_cond_load_acquire() until the target CPU's kick_sync advances. Because the irq_work runs in hardirq context, the waiting CPU cannot reschedule and its own kick_sync never advances. If multiple CPUs form a wait cycle, all CPUs deadlock.

Replace the busy-wait in kick_cpus_irq_workfn() with resched_curr() to force the CPU through do_pick_task_scx(), which queues a balance callback to perform the wait. The balance callback drops the rq lock and enables IRQs following the sched_core_balance() pattern, so the CPU can process IPIs while waiting. The local CPU's kick_sync is advanced on entry to do_pick_task_scx() and continuously during the wait, ensuring any CPU that starts waiting for us sees the advancement and cannot form cyclic dependencies.

AnalysisAI

A deadlock vulnerability in the Linux kernel's sched_ext (extensible scheduler) subsystem allows local authenticated users to trigger a denial of service by creating cyclic wait dependencies between CPUs. The flaw exists in the SCX_KICK_WAIT mechanism where busy-waiting in hardirq context prevents rescheduling and kick_sync advancement, causing multi-CPU deadlocks when wait cycles form. Patch available from mainline kernel (commit c3a7903f65cf for mainline, 415cb193bb97 for stable 6.12+). EPSS score of 0.02% suggests minimal real-world exploitation activity. No public exploit code or active exploitation confirmed at time of analysis.

Technical ContextAI

The sched_ext framework is a relatively new Linux kernel feature that allows BPF programs to implement custom CPU scheduling policies. The vulnerability resides in the inter-processor interrupt (IPI) handling mechanism for CPU kicking. The original implementation performed busy-waiting via smp_cond_load_acquire() in kick_cpus_irq_workfn(), which executes in hardirq context where preemption is disabled. When CPU A waits for CPU B's kick_sync counter to advance while CPU B simultaneously waits for CPU A, both CPUs spin indefinitely without processing interrupts or advancing their own counters. The fix defers the wait operation to a balance callback that runs with interrupts enabled and rq lock dropped (following the sched_core_balance() pattern), allowing CPUs to process IPIs and advance kick_sync counters while waiting. This breaks the cyclic dependency by ensuring continuous forward progress. The root cause is CWE-667 (Improper Locking), specifically a circular wait condition in synchronization primitives.

RemediationAI

Upgrade to Linux kernel 7.0 stable (when released) or apply the upstream patches immediately. For kernel 7.0-rc series, apply commit c3a7903f65cf4c7fb0477eb0f8b94f326a47fe54 from mainline. For stable 6.12.x series, apply commit 415cb193bb9736f0e830286c72a6fa8eb2a9cc5c. Patches are available from https://git.kernel.org/stable/c/c3a7903f65cf4c7fb0477eb0f8b94f326a47fe54 and https://git.kernel.org/stable/c/415cb193bb9736f0e830286c72a6fa8eb2a9cc5c. If immediate patching is not feasible, disable sched_ext functionality by setting CONFIG_SCHED_CLASS_EXT=n during kernel build and recompiling. For running systems, avoid loading BPF programs that utilize custom schedulers via the sched_ext interface. Note that disabling sched_ext removes the ability to use BPF-based scheduling policies but has no impact on default kernel scheduling behavior. This workaround is suitable for systems that enabled the feature experimentally but do not rely on it for production workloads. Monitor for kernel panics or unexplained system hangs as potential indicators of exploitation attempts.

Same weakness CWE-667 – Improper Locking

View all
CVE-2025-43510 HIGH POC
7.8
CVE-2019-5886 CRITICAL POC
9.8
CVE-2020-13246 HIGH POC
7.5
CVE-2019-15513 HIGH POC
7.5
CVE-2019-11599 HIGH POC
7.0
CVE-2023-21400 MEDIUM POC
6.7
CVE-2021-20291 MEDIUM POC
6.5
CVE-2020-12658 CRITICAL
9.8

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

EUVD-2026-28610 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy