CVE-2026-98342 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: wait for RCU readers before releasing dma_device
dma_issue_pending_all() walks the dma_device_list with list_for_each_entry_rcu() under rcu_read_lock(). dma_device_release() unlinks the device with list_del_rcu() and then calls device->device_release() (which in many drivers, such as plx_dma.c, directly calls kfree()).
Because there is no grace period between unlinking the device and freeing it, concurrent RCU readers in dma_issue_pending_all() can access the device after it has been freed.
The lockless walk originally relied on clients holding a dmaengine reference to pin the provider module, and therefore the device, for as long as they might traverse the list. Commit 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") decoupled the dma_device lifetime from the module reference, so the device can now be released while a reader is still walking the list.
Add synchronize_rcu() before the device is freed, so RCU readers are guaranteed to have finished. Keep it unconditional: providers that do not implement device_release() free the device themselves once dma_async_device_unregister() returns. This call will delay for a grace period with dma_list_mutex held, which is safe and only teardown path is delayed.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in the Linux kernel involves a use-after-free condition within the DMA engine subsystem, specifically affecting the interaction between device unregistration and concurrent RCU-protected list traversal. The core issue arises from an improper handling of memory lifecycle during the release phase of dma_device structures. When a DMA device is being removed, the function dma_device_release() executes to unlink the device from the global dma_device_list using list_del_rcu(). Immediately following this unlinking operation, many driver implementations invoke their specific device_release callback, which often results in calling kfree() to deallocate the memory associated with the device structure. This sequence creates a critical window where the data structure is freed while potentially still being accessed by other parts of the kernel that are iterating over the list using RCU read-side primitives.
The operational context for this flaw centers on the function dma_issue_pending_all(), which iterates through all registered DMA devices to issue pending transactions. This iteration relies on rcu_read_lock() and list_for_each_entry_rcu() to safely traverse the linked list without acquiring heavy locks, a standard pattern in Linux kernel development designed to minimize performance overhead. Historically, this lockless walk was safe because clients of the dmaengine subsystem were required to hold a reference count on the underlying provider module. This reference pinning ensured that as long as any client was traversing or using the device list, the module and its associated data structures remained loaded in memory and could not be freed. However, this safety mechanism relied on an implicit coupling between the dma_device lifetime and the module's reference counting scheme.
A significant architectural change introduced by commit 8ad342a86359 decoupled the lifetime of the dma_device structure from the module reference count. This refactoring allowed for more flexible resource management but inadvertently removed the guarantee that prevented premature deallocation. With this separation, it became possible for a device to be unlinked and freed while an RCU read-side critical section was still active in another thread or context. Consequently, concurrent readers executing dma_issue_pending_all() could dereference pointers to devices that had already been returned to the kernel's free pool. This constitutes a classic use-after-free vulnerability, where memory is accessed after it has been invalidated, leading to undefined behavior such as kernel panics, data corruption, or potential privilege escalation if an attacker can control the contents of the freed memory and trigger its reallocation with malicious payloads.
From a classification perspective, this flaw aligns with CWE-416, Use After Free, which describes errors where software uses memory after it has been freed. In terms of adversarial tactics, this vulnerability could be leveraged within the ATT&CK framework under techniques related to execution or defense evasion, particularly if exploited in conjunction with other vulnerabilities to gain arbitrary code execution capabilities on the host system. The impact is severe as it affects core kernel functionality and can destabilize the entire operating system depending on the timing of the race condition and the specific DMA hardware involved.
To mitigate this vulnerability, a synchronization mechanism must be introduced to ensure that all ongoing RCU read-side critical sections have completed before the memory is actually deallocated. The implemented fix adds a call to synchronize_rcu() immediately after unlinking the device from the list but before invoking the device_release callback or freeing the memory. This function blocks until every CPU has exited any RCU read-side critical section that was active at the time of its invocation, effectively establishing a grace period during which no new readers can start and all existing ones are guaranteed to finish. By keeping this call unconditional, the solution remains robust across different driver implementations, including those where device_release is not implemented and the framework handles freeing directly after dma_async_device_unregister returns. This approach ensures that the teardown path correctly waits for RCU safety without compromising system stability or introducing new race conditions, thereby restoring the integrity of memory management within the DMA engine subsystem.