CVE-2025-68333
Deadlock Vulnerability in Linux Kernel sched_ext Deferred IRQ Workfn
Publication date: 2025-12-22
Last updated on: 2026-02-26
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | 6.18 |
| linux | linux_kernel | 6.18 |
| linux | linux_kernel | 6.18 |
| linux | linux_kernel | 6.18 |
| linux | linux_kernel | 6.18 |
| linux | linux_kernel | 6.18 |
| linux | linux_kernel | From 6.12 (inc) to 6.12.68 (exc) |
| linux | linux_kernel | From 6.13 (inc) to 6.17.12 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-667 | The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a possible deadlock in the Linux kernel's deferred_irq_workfn() function when running PREEMPT_RT=y kernels. The issue arises because deferred_irq_workfn() is executed in the per-CPU irq_work task context rather than a hard interrupt context. If the runqueue (rq) returned by container_of() corresponds to the current CPU's rq, a scenario can occur where the rq lock is acquired, an interrupt happens, and then the same rq lock is attempted to be acquired again, causing a deadlock. The fix replaces init_irq_work() with IRQ_WORK_INIT_HARD() to ensure deferred_irq_workfn() always runs in hard-irq context, preventing this deadlock.
How can this vulnerability impact me? :
This vulnerability can cause a deadlock in the Linux kernel on systems using PREEMPT_RT=y kernels, potentially leading to system hangs or degraded performance due to the kernel being stuck waiting for a lock that cannot be acquired. This can affect system stability and responsiveness.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, update your Linux kernel to a version that includes the fix for the deferred_irq_workfn() deadlock issue. The fix involves using IRQ_WORK_INIT_HARD() to initialize rq->scx.deferred_irq_work, ensuring the deferred_irq_workfn() is always invoked in hard-irq context. Applying the latest kernel patches or upgrading to the fixed kernel version is recommended.