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.
| Product | Vendor Advisory | Solution File | Added | Published |
|---|---|---|---|---|
| Debian | — | Upgrade linux | Oct 19, 2026 | Oct 6, 2026 |
| Redhat_linux | — | No solution exists | Oct 13, 2026 | Oct 6, 2026 |
| Vmware Photon_os | — | Use 'tdnf update' to upgrade all packages to the latest version. | Oct 13, 2026 | Oct 6, 2026 |
With curated Threat Intelligence, you can see which vulnerabilities truly put you at risk, prioritize what matters most, and act before attackers do.
Explore Intelligence Hub