CVE-2026-90247 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix mmap_lock leak in irq_work path
stack_map_get_build_id_offset() introduced a per-CPU irq_work to defer mmap_read_unlock() from NMI context, and bpf_find_vma() later reused the same mmap_unlock_work. Both callers only check whether the work is busy before taking mmap_lock, so a nested caller can reuse the slot before the first caller queues it. Two read locks may then be acquired while only one deferred unlock runs, leaking a read lock and blocking exit_mmap().
Reserve the per-CPU slot before mmap_read_trylock(). Use the same wrapper in stackmap and bpf_find_vma() so both callers release the reservation on trylock failure. Keep rejecting the slot while the irq_work remains busy. Release it after the irq_work callback unlocks the mm.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel's BPF subsystem contains a critical concurrency flaw within its memory management interaction logic, specifically involving the handling of mmap locks in non-maskable interrupt contexts. The vulnerability stems from an improper implementation of deferred lock release mechanisms using per-CPU irq_work structures. Specifically, the function stack_map_get_build_id_offset introduced a mechanism to defer the execution of mmap_read_unlock() from NMI context to avoid sleeping in atomic environments. Subsequently, bpf_find_vma reused this same per-CPU slot for its own unlock operations. This architectural decision created a race condition where multiple callers could interact with the shared resource without adequate synchronization, leading to state corruption and resource leaks that compromise system stability.
The core technical flaw lies in the logic used to determine whether the deferred work is available for use. Both stack_map_get_build_id_offset and bpf_find_vma check only if the irq_work structure is currently busy before attempting to acquire mmap_read_trylock(). This simplistic check fails to account for nested execution scenarios where a second caller might observe the slot as free, even though a previous invocation has queued work that has not yet completed. Consequently, two separate read locks can be acquired on the same memory map instance while only one deferred unlock operation is scheduled to run later. This mismatch between lock acquisitions and releases results in a persistent leak of mmap_read_lock references.
The operational impact of this vulnerability is significant for system reliability and security posture. The accumulation of unreleased read locks prevents the mm_struct from being properly released, which directly blocks exit_mmap() operations. In practical terms, this can lead to resource exhaustion on systems running heavy BPF workloads or those subject to frequent process creation and termination cycles involving BPF programs. Over time, the inability to release memory map structures contributes to kernel memory leaks and potential denial of service conditions where processes cannot terminate cleanly due to locked resources held by stale lock references.
This vulnerability aligns with CWE-401, which describes a missing release of resource after effective usage, as well as CWE-362 regarding concurrent execution using shared resources with insufficient synchronization. From an ATT&CK perspective, while this is not directly exploitable for privilege escalation in the traditional sense, it represents a weakness that could be leveraged to cause denial of service against critical system functions, potentially falling under techniques related to resource exhaustion or impact on availability. The flaw highlights the dangers of reusing low-level synchronization primitives without strict ownership semantics across different execution paths within kernel space.
To mitigate this vulnerability, developers must enforce stricter reservation protocols for per-CPU irq_work slots before attempting any lock acquisition. The recommended fix involves reserving the specific per-CPU slot prior to calling mmap_read_trylock(), ensuring that no other caller can interfere with the state of that resource during the critical section. Both stack_map_get_build_id_offset and bpf_find_vma must be updated to use a unified wrapper function that handles this reservation logic consistently. Furthermore, if trylock fails, the reserved slot must be immediately released to prevent stale reservations from blocking future operations. The actual release of the reservation should occur only after the irq_work callback has successfully executed and unlocked the mm structure, thereby guaranteeing that every lock acquisition is matched by a corresponding unlock operation and preventing any leakage of kernel resources.