Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

CVE-2025-37807bpf: Fix kmemleak warning for percpu hashmap

Description

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.

Timeline

  1. ID reserved

    By Linux

  2. · 22 days later

    Published

  3. · 18 months later

    Record updated

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

CVSS scores of CVE-2025-37807, by who scored it
Scored byCVSSScoreVector
NVDNVD · Modified3.1Medium5.5CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS (exploitation in 30 days)
0.25% · top 84% of all CVEs (12 Nov 2026)
CISA SSVC
Exploitation: none · Automatable: no · Technical impact: partial
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: Medium 5.5.

Affected products

  • Linux · Linux

    • affected 824bd0ce6c7c43a9e1e210abf124958e54d88342 – < c5f4b04e1838b9eec426d80500af49cff8631762
    • affected 824bd0ce6c7c43a9e1e210abf124958e54d88342 – < 25014e3dfa6d2fb95c920b9e6b2f0b303baa4533
    • affected 824bd0ce6c7c43a9e1e210abf124958e54d88342 – < 7758e308aeda1038aba1944f7302d34161b3effe
    • affected 824bd0ce6c7c43a9e1e210abf124958e54d88342 – < 1f1c29aa1934177349c17e3c32e68ec38a7a56df
    • affected 824bd0ce6c7c43a9e1e210abf124958e54d88342 – < 11ba7ce076e5903e7bdc1fd1498979c331b3c286
  • Linux · Linux

    • affected 4.6
    • unaffected < 4.6
    • unaffected 6.1.191 – ≤ 6.1.*
    • unaffected 6.6.160 – ≤ 6.6.*
    • unaffected 6.12.26 – ≤ 6.12.*
    • unaffected 6.14.5 – ≤ 6.14.*
    • unaffected 6.15 – ≤ *

References

References5

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2025-37807 badge
[![CVE-2025-37807](https://cveledger.app/badge/CVE-2025-37807.svg)](https://cveledger.app/cve/CVE-2025-37807)

Record last updated .