The vulnerable kernel code contained a logic flaw in the management of “mmap_lock” around the irq_work mechanism. When a nested caller accesses bpf_find_vma() or stack_map_get_build_id_offset() while an earlier call still has a pending irq_work, the same per‑CPU queue is reused before the first work is queued. This allows two read locks to be held simultaneously, but only one deferred unlock is executed, leaking a read lock and blocking exit_mmap(). The result is a kernel hang that denies service to any process attempting to unmap a memory region. The weakness is an uncontrolled resource consumption flaw, corresponding to CWE‑400.

All Linux kernel releases that include the buggy bpf, stack_map_get_build_id_offset, or bpf_find_vma code paths are affected. The vendor is Linux:Linux. No explicit version range is provided, so any kernel build prior to the commit that introduces the patch (see the Git references) is potentially vulnerable.

The EPSS score is less than 1 % and the vulnerability is not listed in CISA’s KEV catalog, indicating a low probability of exploitation. The attack path is not directly disclosed; it is inferred that an attacker would need a kernel or local privileged context capable of loading or executing the affected BPF paths, or otherwise trigger the nested lock reuse. Remote exploitation is unlikely under normal circumstances, so the overall risk remains limited to trusted local users or compromised kernel processes.