CVE-2026-74646 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: take fl->lock when moving mmaps on interrupted invoke
When an invoke is interrupted by a signal, wait_for_completion_interruptible() returns -ERESTARTSYS and fastrpc_internal_invoke() moves every buffer from fl->mmaps onto cctx->invoke_interrupted_mmaps. This list_del()/list_add_tail() walk runs without holding fl->lock, the lock that serialises fl->mmaps in fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else.
Take fl->lock around the move, matching every other fl->mmaps accessor.
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's FastRPC subsystem contains a concurrency vulnerability related to improper lock usage during signal interruption handling. The issue arises within the fastrpc_internal_invoke function when an invocation is interrupted by a pending signal. In such scenarios, the wait_for_completion_interruptible function returns -ERESTARTSYS, triggering a code path that moves memory-mapped buffers from the fl->mmaps list to the cctx->invoke_interrupted_mmaps list. This operation involves standard linked-list manipulation functions, specifically list_del and list_add_tail, which modify the kernel's internal data structures representing active memory mappings for FastRPC sessions.
The core technical flaw is a race condition caused by accessing shared mutable state without holding the appropriate synchronization primitive. The fl->mmaps list is protected by the fl->lock mutex in all other code paths within the subsystem, including fastrpc_req_mmap and fastrpc_req_munmap. However, during the interruption handling sequence, this lock was not acquired before iterating over and modifying the list. This omission creates a window where concurrent operations can access or modify the same memory mapping structures simultaneously. Specifically, other threads performing mmap or munmap requests could interact with the list entries while they are being moved to the interrupted queue, leading to inconsistent state updates within the kernel's virtual memory management subsystem.
This lack of synchronization constitutes a classic race condition vulnerability that falls under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization Race Condition. The absence of proper locking allows for potential data corruption or use-after-free scenarios if an entry is freed by one thread while another is traversing the list to move it. In severe cases, this could lead to kernel panics due to corrupted linked-list pointers or memory access violations when the interrupted buffers are later processed or released. The vulnerability highlights a critical gap in the error handling path of the driver where exception flows were not subjected to the same rigorous locking discipline as normal operational paths.
From an offensive security perspective, this flaw aligns with ATT&CK technique T1059: Command and Scripting Interpreter if exploited for privilege escalation through kernel memory corruption, or more broadly under system exploitation techniques that leverage race conditions in driver code. An attacker who can trigger signal interruptions during FastRPC invocations might exploit the timing window to corrupt kernel data structures, potentially achieving arbitrary code execution with ring zero privileges. The impact is significant as it affects the stability and security of systems relying on Qualcomm's Hexagon DSP communication interface via the Linux kernel.
Mitigation strategies primarily involve applying the upstream kernel patch that introduces fl->lock acquisition around the list manipulation operations in fastrpc_internal_invoke. This ensures mutual exclusion between the interruption handling path and other memory mapping requests, thereby serializing access to the shared resource correctly. System administrators should ensure their kernels are updated with this fix applied. For developers maintaining custom builds or out-of-tree modules, it is imperative to audit all error paths for similar lock omissions, ensuring that any code modifying protected data structures acquires the corresponding mutex before execution. Regular static analysis and concurrency testing tools can help identify such synchronization gaps in complex kernel subsystems like FastRPC.