Answer in brief
CVE-2025-37807 records a Unknown severity vulnerability in bpf: Fix kmemleak warning for percpu hashmap. 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 | >=824bd0ce6c7c43a9e1e210abf124958e54d88342 <25014e3dfa6d2fb95c920b9e6b2f0b303baa4533 || >=824bd0ce6c7c43a9e1e210abf124958e54d88342 <7758e308aeda1038aba1944f7302d34161b3effe || >=824bd0ce6c7c43a9e1e210abf124958e54d88342 <1f1c29aa1934177349c17e3c32e68ec38a7a56df || >=824bd0ce6c7c43a9e1e210abf124958e54d88342 <11ba7ce076e5903e7bdc1fd1498979c331b3c286 | 25014e3dfa6d2fb95c920b9e6b2f0b303baa4533, 7758e308aeda1038aba1944f7302d34161b3effe, 1f1c29aa1934177349c17e3c32e68ec38a7a56df, 11ba7ce076e5903e7bdc1fd1498979c331b3c286 |
| Linux/Linuxgeneric | 4.6 | Not reported |
Published upstream
May 8, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 21, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 21, 2026
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kmemleak warning for percpu hashmap Vlad Poenaru reported the following kmemleak issue: unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr; Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak. In htab_map_alloc(), we already have htab->elem_size = sizeof(struct htab_elem) + round_up(htab->map.key_size, 8); if (percpu) htab->elem_size += sizeof(void *); else htab->elem_size += round_up(htab->map.value_size, 8); So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too. The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.
Quoted source text, attributed separately from HOL analysis.