CVE-2026-90342 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix mmap_lock deadlock on arena lock failure
Reported by the Sashiko AI review.
arena_vm_fault() returns VM_FAULT_RETRY when it can't take arena->spinlock, but it never took mmap_lock. The fault path assumes a VM_FAULT_RETRY handler already dropped mmap_lock and re-takes it on the retry, so mmap_lock gets taken twice and can deadlock:
do_user_addr_fault() {
fault = handle_mm_fault(...); // calls arena_vm_fault() if (fault & VM_FAULT_RETRY) goto retry; // re-locks mmap_lock mmap_read_unlock(mm); }
Return VM_FAULT_SIGBUS instead, for two reasons:
1. We could keep VM_FAULT_RETRY, but then we'd have to drop the fault lock first and cap the retry ourselves, the way __folio_lock_or_retry() does.
2. A failed raw_res_spin_lock_irqsave() already means a possible deadlock was detected, so retrying just hits the same lock again.
So returning VM_FAULT_RETRY here is overkill.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel contains a concurrency vulnerability within the BPF subsystem related to memory management and locking primitives during page fault handling. Specifically, the function arena_vm_fault interacts with the virtual memory area (VMA) infrastructure in a manner that violates expected lock ordering protocols. When this function is unable to acquire the arena spinlock due to contention or other resource constraints, it returns VM_FAULT_RETRY to signal the caller that the operation should be retried later. However, at the point of failure, the mmap_lock has not been released by arena_vm_fault itself. This creates a critical inconsistency because the higher-level fault handler in do_user_addr_fault assumes that any return value indicating retry implies that all necessary locks have already been dropped to allow for safe re-entry.
The operational impact arises from this assumption mismatch within the kernel's page fault path. When handle_mm_fault invokes arena_vm_fault and receives VM_FAULT_RETRY, it proceeds directly to a retry label without releasing the mmap_lock held by the current context. Upon reaching the retry point, the code attempts to reacquire the mmap_lock. Since the lock was never released in the initial attempt due to the early return on spinlock failure, this results in an immediate deadlock condition where the kernel thread blocks indefinitely waiting for a lock it already holds but cannot re-acquire because of recursive locking restrictions or simple contention logic that does not support self-deadlocking without explicit handling. This effectively causes a denial of service by hanging the process involved in the memory access and potentially impacting system stability if such faults occur frequently under high load conditions involving BPF programs with arena allocations.
From a vulnerability classification perspective, this issue aligns with CWE-833 Lock Without Unlock or improper release of resources leading to resource exhaustion, as well as CWE-674 Uncontrolled Recursion which can lead to stack overflow or deadlock in concurrent systems. In the context of the MITRE ATT&CK framework for enterprise security, this type of kernel-level denial of service could be leveraged by an attacker who has achieved code execution within a container or unprivileged user space to destabilize the host system through resource exhaustion attacks targeting memory management subsystems. The vulnerability highlights the complexity of maintaining correct lock ordering in complex kernel subsystems where multiple locking hierarchies intersect, particularly when dealing with asynchronous operations and retry mechanisms that must strictly adhere to caller expectations regarding state preservation.
The resolution involves modifying arena_vm_fault to return VM_FAULT_SIGBUS instead of VM_FAULT_RETRY when it fails to acquire the arena spinlock. This change is technically sound because a failure to lock in this specific context often indicates underlying contention or potential deadlock scenarios already detected by lower-level locking primitives like raw_res_spin_lock_irqsave. Returning SIGBUS appropriately signals to the user-space process that the memory access cannot be completed due to an internal resource constraint, rather than suggesting a transient condition suitable for retrying without proper state cleanup. This approach avoids the need for complex manual lock dropping and retry capping logic which would increase code complexity and potential for further race conditions. It ensures that the fault handler does not attempt to re-acquire locks in an invalid state, thereby preventing the deadlock scenario entirely while providing a clear error signal to applications relying on BPF arena memory mappings.
Mitigation strategies involve applying the upstream kernel patch that corrects this return value logic within the bpf_arena implementation. System administrators should ensure their kernels are updated to versions containing this fix to prevent potential denial of service vulnerabilities arising from concurrent BPF program execution and memory allocation failures. For developers integrating or extending BPF functionality, it is crucial to adhere strictly to kernel locking conventions where any function returning retry codes must guarantee that all held locks are released before the return statement executes. This incident serves as a reminder of the importance of rigorous static analysis and formal verification in critical path code such as memory management interfaces within operating system kernels.