CVE-2026-74574 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open()
The failed_dev_add and failed_dev_name paths drop the file-device reference while wq->wq_lock is still held. If put_device(fdev) drops the last reference, idxd_file_dev_release() runs synchronously and tries to take wq->wq_lock again, deadlocking.
Those paths also fall through into the later ctx cleanup labels even though idxd_file_dev_release() owns that cleanup and frees ctx. This can make idxd_xa_pasid_remove(ctx) and kfree(ctx) operate on a freed context.
Move idxd_wq_get() before file-device setup can fail, since the release callback always calls idxd_wq_put(). Then unlock wq->wq_lock before put_device(fdev) and return directly from the file-device setup failure path, leaving ctx cleanup to the release callback.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's dmaengine subsystem, specifically affecting the Intel Data Center DAX (idxd) driver implementation. The flaw manifests in the idxd_cdev_open() function where improper resource management during device setup creates a critical deadlock condition and memory corruption scenario. The issue stems from the incorrect ordering of operations during error handling paths, particularly when dealing with file-device references and work queue locking mechanisms.
The technical root cause involves a classic deadlock pattern occurring when the failed_dev_add and failed_dev_name error paths execute while holding the wq->wq_lock mutex. When put_device(fdev) is called within these cleanup sequences, it may trigger the synchronous execution of idxd_file_dev_release() function. This release callback attempts to reacquire the same wq->wq_lock that is already held by the calling context, creating an immediate deadlock situation. The vulnerability aligns with CWE-362 (Concurrent Execution using Shared Resource with Unprotected Critical Section) and represents a classic mutex deadlock scenario.
Additionally, the error handling paths exhibit improper fall-through behavior where execution continues into later cleanup labels even though idxd_file_dev_release() already owns the responsibility for cleaning up the context structure. This leads to double-free conditions and use-after-free vulnerabilities when functions like idxd_xa_pasid_remove(ctx) and kfree(ctx) attempt to operate on memory that has already been freed. The flaw demonstrates characteristics of CWE-415 (Double Free) and CWE-416 (Use After Free) through the improper context management during error recovery.
The proposed mitigation strategy addresses these issues by reordering operations to ensure idxd_wq_get() is called before any file-device setup can potentially fail, establishing proper reference counting relationships. The fix requires releasing wq->wq_lock before invoking put_device(fdev), breaking the deadlock cycle. Furthermore, the error paths now return directly from the file-device setup failure conditions rather than falling through to context cleanup labels, ensuring that only one cleanup path executes and that the release callback maintains exclusive ownership of context deallocation. This approach aligns with ATT&CK technique T1499.004 (Virtualization/Sandbox Evasion) mitigation patterns through proper resource lifecycle management and prevents the exploitation of race conditions in kernel memory management.
The vulnerability represents a significant security risk in systems utilizing Intel Data Center DAX hardware, as it could potentially allow privilege escalation or system instability through carefully crafted device open operations. The fix ensures proper locking semantics while maintaining the integrity of the driver's resource management state machine. This remediation approach follows established kernel development practices for preventing deadlock conditions and memory corruption in concurrent kernel subsystems, particularly those involving device management and work queue operations that are fundamental to the Linux kernel's I/O processing pipeline.