CVE-2022-48867 in Linux
Summary
by MITRE • 08/21/2024
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Prevent use after free on completion memory
On driver unload any pending descriptors are flushed at the time the interrupt is freed: idxd_dmaengine_drv_remove() -> drv_disable_wq() -> idxd_wq_free_irq() -> idxd_flush_pending_descs().
If there are any descriptors present that need to be flushed this flow triggers a "not present" page fault as below:
BUG: unable to handle page fault for address: ff391c97c70c9040 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page
The address that triggers the fault is the address of the descriptor that was freed moments earlier via: drv_disable_wq()->idxd_wq_free_resources()
Fix the use after free by freeing the descriptors after any possible usage. This is done after idxd_wq_reset() to ensure that the memory remains accessible during possible completion writes by the device.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/17/2026
The vulnerability described in CVE-2022-48867 represents a critical use-after-free condition within the Linux kernel's DMA engine subsystem, specifically affecting the Intel Data Center DAX (idxd) driver. This flaw occurs during driver unloading when the system attempts to handle pending DMA descriptors that are already in the process of being freed, creating a scenario where memory that has been released is still being accessed. The issue manifests as a page fault error during the driver removal sequence, indicating that the kernel is attempting to read from memory that has already been deallocated, which can lead to system instability or potential privilege escalation.
The technical implementation of this vulnerability involves the interaction between multiple driver functions during the removal process, specifically within the idxd_dmaengine_drv_remove() function chain. When the driver is unloaded, the system calls drv_disable_wq() which subsequently invokes idxd_wq_free_irq() and then idxd_flush_pending_descs(). The sequence of operations creates a race condition where descriptors are freed through idxd_wq_free_resources() but are still being referenced during the flush operation, resulting in memory access violations. This pattern demonstrates a classic use-after-free vulnerability where the memory management logic fails to properly sequence the freeing of resources with their final usage, creating a temporal gap where freed memory can still be accessed.
The operational impact of this vulnerability extends beyond simple system crashes, as it represents a potential security risk that could be exploited by malicious actors to gain unauthorized access to system resources. The page fault error code 0x0000 indicates a not-present page access, which is a clear indicator of memory corruption that could be leveraged for privilege escalation attacks. This vulnerability affects systems utilizing Intel Data Center DAX hardware accelerators, which are commonly found in high-performance computing environments and data centers where DMA operations are frequent. The flaw is particularly concerning because it occurs during normal driver lifecycle operations, meaning it could be triggered during system maintenance or unexpected shutdown scenarios.
The fix implemented for this vulnerability addresses the root cause by reordering the memory management operations to ensure that all pending descriptor completions are processed before the memory is freed. By moving the descriptor freeing operation to occur after idxd_wq_reset(), the system ensures that any potential completion writes from the hardware device can access the memory without triggering page faults. This remediation aligns with security best practices for memory management in kernel space and follows the principles outlined in CWE-416, which specifically addresses use-after-free vulnerabilities. The solution demonstrates proper resource management by ensuring that memory remains accessible during all possible completion paths, thereby preventing the temporal gap that allowed the vulnerability to exist. The fix also reflects the ATT&CK framework's approach to mitigating kernel-level vulnerabilities through proper memory lifecycle management and resource synchronization, preventing adversaries from exploiting temporal inconsistencies in memory deallocation patterns.