Improper Locking Affecting linux-qemu-6.18 package, versions <6.18.38-r2


Severity

Recommended
0.0
medium
0
10

Snyk's Security Team recommends NVD's CVSS assessment. Learn more

Threat Intelligence

EPSS
0.08% (1st percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-CHAINGUARDLATEST-LINUXQEMU618-17996171
  • published16 Jul 2026
  • disclosed8 May 2026

Introduced: 8 May 2026

CVE-2026-43326  (opens in a new tab)
CWE-667  (opens in a new tab)

How to fix?

Upgrade Chainguard linux-qemu-6.18 to version 6.18.38-r2 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream linux-qemu-6.18 package and not the linux-qemu-6.18 package as distributed by Chainguard. See How to fix? for Chainguard relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1