CVE-2026-98343 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fix use-after-free in dma_chan_put() and dma_release_channel()
When dma_device_put() drops the last reference on chan->device->ref, dma_device_release() runs and may free the dma_device along with its channels.
dma_chan_put() then still reads chan->device->owner via dma_chan_to_owner() for the trailing module_put(). KASAN catches it:
slab-use-after-free in dma_chan_put+0x3e6/0x4c0 Read of size 8 by task insmod/6319 Freed by task 6319: kfree+0x225/0x470 dma_chan_put+0x395/0x4c0 dmaengine_put+0xf8/0x160
Cache the module owner in dma_chan_put() before the put so the trailing module_put() does not need chan->device.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel contains a critical use-after-free vulnerability within the DMA engine subsystem, specifically affecting the functions dma_chan_put and dma_release_channel. This flaw arises from an improper handling of reference counting when releasing DMA channel resources. The core issue lies in the sequence of operations during device teardown, where memory is freed while still being accessed by subsequent code paths that assume the underlying structures remain valid.
The vulnerability manifests when dma_device_put decrements the reference count on a DMA device's ref counter and determines it has reached zero. At this point, the kernel invokes dma_device_release to clean up the device structure. This function proceeds to free the memory associated with the dma_device object as well as its embedded channel structures. However, immediately following this deallocation, the execution flow may still invoke dma_chan_put for channels that were part of the now-freed device. Inside dma_chan_put, the code attempts to retrieve the module owner by calling dma_chan_to_owner on chan->device. Since chan->device points into memory that has already been returned to the kernel's slab allocator and potentially reused or marked as freed, this access constitutes a use-after-free condition.
This specific flaw allows for potential denial of service through system crashes or data corruption if an attacker can trigger the race condition between device release and channel cleanup. The Kernel Address Sanitizer (KASAN) has identified this issue by detecting invalid reads from slab memory that was previously freed via kfree within dma_chan_put itself during a recursive put operation triggered by insmod processes. Such vulnerabilities are particularly dangerous in kernel space because they can lead to privilege escalation if the corrupted data is exploited to overwrite function pointers or other critical control structures, although the immediate impact observed is typically a kernel panic due to invalid memory access.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, which describes situations where software continues to use a pointer after it has been freed, leading to undefined behavior and potential security breaches. In terms of attack vectors, this falls under the broader category of resource management errors that could be leveraged in local privilege escalation scenarios if combined with other exploitation techniques, though primarily it represents a stability issue exploitable for denial of service against kernel services managing DMA channels.
The remediation strategy implemented involves caching the module owner reference within dma_chan_put before performing any operations that might trigger device release or channel deallocation. By storing the pointer to the owning module early in the function execution flow, the trailing call to module_put can safely decrement the reference count without needing to access chan->device again. This ensures that even if the device structure is freed concurrently by another thread or context during the cleanup process, the necessary information required for proper resource management has already been securely captured and remains valid until use.
To mitigate similar issues in broader systems engineering practices, developers should adhere strictly to reference counting protocols where all dependent data structures are validated before access. Implementing defensive programming techniques such as nullifying pointers after free operations can also help prevent accidental reuse of freed memory. Furthermore, continuous integration pipelines incorporating static analysis tools and runtime sanitizers like KASAN or AddressSanitizer are essential for detecting these subtle timing-dependent bugs early in the development lifecycle. Organizations relying on Linux-based infrastructure should ensure their kernels are updated to versions containing this patch to maintain system integrity and availability against potential kernel-level disruptions caused by DMA subsystem anomalies.