CVE-2026-74354 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Take mmap_lock in zap_pages()
zap_vma_range() requires the owning mm's mmap_lock to be held.
Taking mmap_read_lock under arena->lock would AB-BA against arena_vm_close() and arena_map_mmap(), both of which run with mmap_write_lock held and then acquire arena->lock. Instead drop arena->lock, mmget_not_zero() the vma's mm, take mmap_read_lock, and re-resolve the vma via find_vma() since it may have been unmapped or replaced while waiting.
Track processed vmls with a per-call generation in vml->zap_gen and serialize zap_pages() callers with a new arena->zap_mutex so concurrent callers on different uaddr ranges do not mark each other's vmls processed before the zap is done.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's eBPF subsystem and represents a complex concurrency issue that could lead to memory corruption and potential privilege escalation. The flaw manifests in the bpf implementation's handling of memory mapping operations, specifically within the zap_pages() function that manages virtual memory cleanup during BPF program execution. The vulnerability stems from improper locking order and race condition management when processing virtual memory regions, creating a scenario where multiple kernel threads can simultaneously manipulate the same memory mappings without proper synchronization.
The technical root cause involves an AB-BA deadlock pattern between different lock acquisition sequences. The zap_vma_range() function requires holding the memory manager's mmap_lock to ensure consistent access to virtual memory areas. However, when the code attempts to take mmap_read_lock under arena->lock, it creates a circular dependency that can result in deadlocks. Specifically, the arena_vm_close() and arena_map_mmap() functions hold mmap_write_lock and subsequently acquire arena->lock, while zap_pages() attempts the reverse order. This lock ordering violation creates a classic deadlock scenario where each function waits for the other to release its locks.
The implementation flaw extends beyond simple deadlock prevention to include incorrect memory management practices during concurrent execution. When processing virtual memory areas, the code must properly handle the case where virtual memory mappings may change while waiting for locks. The solution requires dropping the arena->lock, acquiring a reference to the memory manager with mmget_not_zero(), taking the appropriate mmap_read_lock, and then re-resolving the VMA through find_vma() since the mapping might have been modified or removed during the wait period. This approach ensures that the system operates on current virtual memory mappings rather than potentially stale references.
The operational impact of this vulnerability spans multiple security domains and could enable various attack vectors. A malicious user with access to BPF program execution capabilities could exploit this weakness to cause kernel crashes, leading to denial of service conditions, or potentially escalate privileges through memory corruption attacks. The vulnerability is particularly concerning because it affects the core kernel memory management subsystem that underpins all BPF operations, making it a critical security concern for systems running BPF programs. Attackers could leverage this flaw to manipulate virtual memory mappings in ways that compromise system integrity and stability.
The mitigation strategy involves implementing proper serialization mechanisms through a new arena->zap_mutex to ensure that concurrent zap_pages() callers do not interfere with each other's processing. Additionally, the solution introduces per-call generation tracking using vml->zap_gen to prevent multiple callers from marking the same virtual memory regions as processed before the complete operation is finished. This approach aligns with established security practices for preventing race conditions in kernel code and follows the principles outlined in CWE-362 for concurrent execution issues. The fix also addresses ATT&CK technique T1059 by ensuring proper memory management during program execution, preventing potential exploitation through kernel memory corruption attacks.
This vulnerability demonstrates the complexity of kernel-level concurrency control and highlights the importance of careful lock ordering analysis in security-critical code. The solution requires careful consideration of memory management patterns and proper synchronization primitives to prevent both deadlock conditions and race hazards that could compromise system security. The fix maintains backward compatibility while addressing fundamental issues in the BPF subsystem's memory handling, ensuring that virtual memory operations remain consistent and secure under concurrent access patterns typical in modern multi-threaded kernel environments.