Answer in brief
CVE-2026-90247 records a Unknown severity vulnerability in bpf: Fix mmap_lock leak in irq_work path. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=eac9153f2b584c702cea02c1f1a57d85aa9aea42 <a052ad5edccf5319f50ed955de4368f8318a9f20 || >=eac9153f2b584c702cea02c1f1a57d85aa9aea42 <051f2da26ce377f683b938a3382e0f16d02f3139 || >=eac9153f2b584c702cea02c1f1a57d85aa9aea42 <fa9dcacdcdf487f0ffef64bf67622f1caed509f1 || a7f4da875c16f3b8bef0d9ec67528111045bfcd8 || f1838da73cccb238b8be4ef464fce0168dc7ba84 || >=4.19.92 <4.20 || >=5.4.7 <5.5 | a052ad5edccf5319f50ed955de4368f8318a9f20, 051f2da26ce377f683b938a3382e0f16d02f3139, fa9dcacdcdf487f0ffef64bf67622f1caed509f1, 4.20, 5.5 |
| Linux/Linuxgeneric | 5.5 | Not reported |
Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 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.
Quoted source text, attributed separately from HOL analysis.