CVE-2024-35991: dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
drain_workqueue() cannot be called safely in a spinlocked context due to
possible task rescheduling. In the multi-task scenario, calling
queue_work() while drain_workqueue() will lead to a Call Trace as
pushing a work on a draining workqueue is not permitted in spinlocked
context.
Call Trace:
<TASK>
? __warn+0x7d/0x140
? __queue_work+0x2b2/0x440
? report_bug+0x1f8/0x200
? handle_bug+0x3c/0x70
? exc_invalid_op+0x18/0x70
? asm_exc_invalid_op+0x1a/0x20
? __queue_work+0x2b2/0x440
queue_work_on+0x28/0x30
idxd_misc_thread+0x303/0x5a0 [idxd]
? __schedule+0x369/0xb40
? __pfx_irq_thread_fn+0x10/0x10
? irq_thread+0xbc/0x1b0
irq_thread_fn+0x21/0x70
irq_thread+0x102/0x1b0
? preempt_count_add+0x74/0xa0
? __pfx_irq_thread_dtor+0x10/0x10
? __pfx_irq_thread+0x10/0x10
kthread+0x103/0x140
? __pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x50
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK>
The current implementation uses a spinlock to protect event log workqueue
and will lead to the Call Trace due to potential task rescheduling.
To address the locking issue, convert the spinlock to mutex, allowing
the drain_workqueue() to be called in a safe mutex-locked context.
This change ensures proper synchronization when accessing the event log
workqueue, preventing potential Call Trace and improving the overall
robustness of the code.
Security readout for executives and security teams
Plain-English summary
CVE-2024-35991 is a Linux kernel reliability flaw in the idxd DMA engine driver. A locking mistake can allow unsafe workqueue draining and trigger a kernel call trace. The source bundle describes a kernel fix, but gives no CVSS score, CWE, or confirmed real-world exploitation.
Executive priority
Treat this as a kernel maintenance and reliability issue unless local evidence shows repeated crashes or warnings. There is no source-backed evidence of active exploitation, but exposed systems using idxd should receive timely kernel updates.
Technical view
The idxd driver protected event log workqueue access with a spinlock while calling drain_workqueue(), which can reschedule and is unsafe in spinlocked context. Concurrent queue_work() during draining can trigger a warning call trace. The fix converts that lock to a mutex so workqueue draining occurs in a sleepable context.
Likely exposure
Exposure appears limited to Linux systems running affected kernel builds with the dmaengine idxd driver path present or in use. The bundle lists Linux 6.4, 6.6.30, 6.8.9, and 6.9 as affected, but distro backport status is not provided.
Exploitation context
No active exploitation is supported by the bundle. The CVE is not listed as KEV, and the description frames the issue as a synchronization bug causing a call trace rather than a documented attacker technique.
Researcher notes
The available evidence supports a concurrency defect in the Linux idxd driver workqueue locking model. Impact details are incomplete: no CVSS, CWE, exploitability analysis, privilege requirement, or distro-specific affected matrix is included in the provided bundle.
Mitigation direction
Check your Linux vendor advisory for patched kernel packages or backports.
Update affected kernels to builds containing the referenced stable commits.
Prioritize systems using idxd, Intel DSA, or related DMA acceleration features.
If idxd is unnecessary, consider disabling it through approved operational change control.
Monitor kernel logs for recurring idxd workqueue call traces until patched.
Validation and detection
Inventory Linux kernel versions across exposed fleets and appliances.
Confirm whether the idxd driver or related hardware acceleration is present.
Verify vendor kernel changelogs include the referenced stable fixes.
Review kernel logs for call traces mentioning idxd, queue_work, or drain_workqueue.
Track remediation separately for distro kernels because backports may change version evidence.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-35991 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.