CVE-2026-90247
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's handling of certain performance and memory tools could let specially timed operations leave a lock held, eventually freezing processes when they try to release memory.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in per-CPU irq_work slot reuse between stack_map_get_build_id_offset and bpf_find_vma allows nested mmap_read_trylock calls without corresponding unlocks, leaking a read lock on the mm_struct and blocking exit_mmap.
Why it matters to the business
Systems running BPF programs that exercise stack maps or VMA lookups can experience process hangs during memory unmapping, reduced stability under load, and potential kernel-level denial of service in environments with high BPF usage.
How an attack unfolds
An attacker crafts or triggers concurrent BPF operations that invoke the affected functions from NMI and process contexts, causing the per-CPU work slot to be reused before the first deferred unlock completes, resulting in a leaked mmap read lock.
How to fix it
Apply the upstream fix that reserves the per-CPU slot before trylock and uses a common wrapper in both callers; upgrade to a Linux kernel containing the resolution of CVE-2026-90247.
How to confirm the fix worked
Verify the patch is present by inspecting the bpf and stackmap code for slot reservation before mmap_read_trylock and unified release logic; test with concurrent stackmap and VMA workloads to confirm no lock leaks occur.
Typical attack path
- Load or attach a BPF program that exercises stack map build ID or VMA lookup paths
- Trigger NMI and process-context calls to the shared irq_work slot in rapid succession
- Cause reuse of the busy slot before the first mmap_read_unlock is deferred
- Accumulate unmatched read locks until exit_mmap blocks
How to detect it
Search kernel logs and process traces for repeated entries in exit_mmap or mmap_lock contention warnings; inspect BPF program load/attach events and NMI-related stack traces for signs of the affected paths.
What your security team should do
- Prioritize kernel updates for any systems running untrusted or complex BPF programs
- Monitor for processes stuck in exit_mmap after applying the fix
- Limit unprivileged BPF access until kernels are updated
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|