CVE-2026-74647 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: Remove buffer from list prior to unmap operation
fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if multiple threads invoke unmap concurrently, where one thread may remove the entry from the list while another thread's unmap operation is still ongoing.
Fix this by removing the buffer entry from the list before calling the unmap operation. If the unmap fails, the entry is re-added to the list so that userspace can retry the unmap, or alternatively, the buffer will be cleaned up during device release when the DSP process is torn down and all DSP-side mappings are freed along with remaining buffers in the list.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel driver for Qualcomm's FastRPC interface contains a concurrency flaw within its memory unmapping logic that can lead to race conditions under specific multi-threaded access patterns. The vulnerability resides specifically in the fastrpc_req_munmap_impl function, which is responsible for releasing previously mapped buffers associated with Digital Signal Processor operations. In the flawed implementation, the sequence of operations involves first unmapping the buffer from the DSP hardware context and subsequently removing the corresponding entry from an internal kernel list that tracks active mappings. This ordering creates a critical window where the buffer remains listed as active while its underlying resources are being released or in transition states within the driver subsystem.
This architectural oversight allows for potential race conditions when multiple threads concurrently invoke unmap operations on different buffers or even overlapping contexts. If one thread initiates an unmap and begins the hardware release process, another thread may simultaneously attempt to access or manipulate the same list structure before the first thread has completed its removal of the entry from the data structure. Because standard kernel lists are not inherently safe for concurrent modification without explicit locking mechanisms covering both the traversal and modification phases in this specific sequence, such concurrency can result in corrupted list pointers, use-after-free scenarios if the buffer memory is reclaimed prematurely, or general instability within the driver's state management subsystem. The risk is exacerbated by the asynchronous nature of DSP communication where hardware completion times may vary, leaving the software-side data structures out of sync with actual resource states for a non-trivial duration.
The operational impact of this vulnerability includes potential system crashes, kernel panics, or undefined behavior when concurrent unmap requests are processed. In worst-case scenarios involving memory corruption due to list structure damage, an attacker who can trigger these race conditions through local user-space applications might achieve arbitrary code execution with the privileges of the kernel. Even without successful exploitation for privilege escalation, the instability caused by corrupted data structures can lead to denial-of-service conditions where the FastRPC subsystem becomes unresponsive or requires a full system reboot to restore proper functionality. The vulnerability highlights the importance of atomicity in resource management sequences within high-concurrency driver environments.
The resolution involves reordering the operations within fastrpc_req_munmap_impl to ensure that the buffer entry is removed from the tracking list before initiating the actual unmap operation with the DSP hardware. This change ensures that any subsequent concurrent access attempts will see the buffer as already removed, thereby preventing race conditions on the shared data structure. To maintain robustness and prevent resource leaks in case of transient hardware errors during the unmapping process, the fix includes logic to re-add the entry back into the list if the unmap operation fails. This allows user-space applications to retry the request safely. Furthermore, a safety net is maintained where any remaining buffers that were not successfully cleaned up are automatically freed when the device is released and the DSP process is torn down, ensuring no memory leaks persist across driver load cycles.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The specific mechanism of accessing a data structure while it is being modified by another thread without adequate mutual exclusion falls squarely under this category. In terms of the MITRE ATT&CK framework for enterprise security, this type of flaw could be leveraged in techniques related to privilege escalation or defense evasion if an attacker can reliably trigger the race condition to crash the system or corrupt kernel memory structures. Mitigation strategies primarily rely on applying the provided kernel patch which corrects the ordering logic and ensures proper synchronization primitives are respected during resource lifecycle management. System administrators should ensure that their Linux kernels are updated with this fix applied, particularly in environments where FastRPC is actively used for offloading computational tasks to DSPs, such as in mobile devices or embedded systems running Qualcomm SoCs. Regular auditing of driver code for similar race conditions involving shared lists and asynchronous hardware operations is recommended to prevent analogous vulnerabilities in other subsystems.