https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 03:07:23 +0000 https://vulnerability.circl.lu/vuln/cve-2026-98342 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dmaengine: wait for RCU readers before releasing dma_device</p> <p>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-&gt;device_release() (which in many drivers, such as plx_dma.c, directly calls kfree()).</p> <p>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.</p> <p>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 (&#34;dmaengine: Add reference counting to dma_device struct&#34;) decoupled the dma_device lifetime from the module reference, so the device can now be released while a reader is still walking the list.</p> <p>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.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dmaengine: wait for RCU readers before releasing dma_device</p> <p>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-&gt;device_release() (which in many drivers, such as plx_dma.c, directly calls kfree()).</p> <p>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.</p> <p>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 (&#34;dmaengine: Add reference counting to dma_device struct&#34;) decoupled the dma_device lifetime from the module reference, so the device can now be released while a reader is still walking the list.</p> <p>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.</p> https://vulnerability.circl.lu/vuln/cve-2026-98342