Cloudanix VulnDB

CVE-2026-98342

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's management of certain hardware communication devices can let memory be used after it has already been freed, which may cause crashes or allow an attacker with local access to interfere with the system.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in dmaengine: dma_issue_pending_all() performs an RCU-protected walk of dma_device_list while dma_device_release() performs list_del_rcu() followed immediately by kfree() of the device (or device_release()), allowing concurrent readers to dereference a freed dma_device after the grace period was removed by prior reference-counting changes.

Why it matters to the business

Kernel crashes, memory corruption, or potential local privilege escalation on systems using DMA engine drivers; delayed or failed hardware offload operations; elevated urgency for any environment running recent mainline kernels that adopted the reference-counting change.

How an attack unfolds

An attacker with local access triggers repeated registration/unregistration of a DMA device while concurrently invoking dma_issue_pending_all() (via userspace DMA submission paths) to race the RCU reader against the immediate free, achieving a use-after-free dereference inside the list walk.

How to fix it

Upgrade to a kernel containing the fix that inserts an unconditional synchronize_rcu() before any device free in dma_device_release(); rebuild and reboot all affected systems; for distributions, apply the vendor backport that restores the grace period on the dma_list_mutex teardown path.

How to confirm the fix worked

Confirm the presence of synchronize_rcu() immediately after list_del_rcu() inside dma_device_release() or dma_async_device_unregister(); run targeted concurrency tests exercising dma_issue_pending_all() during device teardown; verify no use-after-free reports in kmemleak or KASAN during stress of DMA provider load/unload.

Typical attack path

  1. Obtain local unprivileged access on a Linux system exposing DMA engine devices
  2. Repeatedly register and unregister DMA providers to drive device release paths
  3. Concurrently submit DMA transactions that invoke dma_issue_pending_all() under rcu_read_lock()
  4. Trigger the race to obtain a dangling dma_device pointer after kfree()
  5. Leverage the freed object for memory corruption or information leak

How to detect it

Inspect kernel logs for use-after-free or slab corruption reports involving dma_device structures during device registration or DMA submission; correlate crashes with concurrent calls to dma_async_device_unregister() and dma_issue_pending_all(); review audit logs for unusual patterns of DMA provider load/unload by unprivileged processes.

What your security team should do

  • Prioritize kernel updates on any system exposing DMA engine hardware or using drivers that call dma_async_device_unregister()
  • Enable KASAN or kernel memory debugging on test systems to validate the fix before broad rollout
  • Restrict unprivileged DMA device access via cgroups or driver permissions until patches are applied
  • Monitor for kernel oops or slab corruption events correlated with DMA activity

The record

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.

Affected packages

Ecosystem Package Introduced Fixed