CVE-2026-90247: bpf: Fix mmap_lock leak in irq_work path
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix mmaplock leak in irqwork path
stackmapgetbuildidoffset() introduced a per-CPU irqwork to defer mmapreadunlock() from NMI context, and bpffindvma() later reused the same mmapunlockwork. Both callers only check whether the work is busy before taking mmaplock, 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 exitmmap().
Reserve the per-CPU slot before mmapreadtrylock(). Use the same wrapper in stackmap and bpffindvma() so both callers release the reservation on trylock failure. Keep rejecting the slot while the irqwork remains busy. Release it after the irqwork callback unlocks the mm.
Affected Software
Event History
Frequently Asked Questions
What execution pattern is required to trigger the leaked lock?
A nested caller must reuse the shared per-CPU mmap unlock work slot after the first caller has checked that it is not busy but before that caller queues its deferred irq_work. This can result in two mmap read locks being acquired while only one deferred unlock is performed.
How does the fix avoid leaving the per-CPU slot reserved when locking fails?
The corrected code reserves the per-CPU slot before calling mmap_read_trylock() and releases that reservation if the trylock fails. The reservation remains unavailable while the irq_work is busy and is released after the callback unlocks the mm.