{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-05-03T01:34:05.171","vulnerabilities":[{"cve":{"id":"CVE-2025-37807","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2025-05-08T07:15:51.873","lastModified":"2025-11-10T17:32:35.180","vulnStatus":"Analyzed","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kmemleak warning for percpu hashmap\n\nVlad Poenaru reported the following kmemleak issue:\n\n  unreferenced object 0x606fd7c44ac8 (size 32):\n    backtrace (crc 0):\n      pcpu_alloc_noprof+0x730/0xeb0\n      bpf_map_alloc_percpu+0x69/0xc0\n      prealloc_init+0x9d/0x1b0\n      htab_map_alloc+0x363/0x510\n      map_create+0x215/0x3a0\n      __sys_bpf+0x16b/0x3e0\n      __x64_sys_bpf+0x18/0x20\n      do_syscall_64+0x7b/0x150\n      entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFurther investigation shows the reason is due to not 8-byte aligned\nstore of percpu pointer in htab_elem_set_ptr():\n  *(void __percpu **)(l->key + key_size) = pptr;\n\nNote that the whole htab_elem alignment is 8 (for x86_64). If the key_size\nis 4, that means pptr is stored in a location which is 4 byte aligned but\nnot 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based\non 8 byte stride, so it won't detect above pptr, hence reporting the memory\nleak.\n\nIn htab_map_alloc(), we already have\n\n        htab->elem_size = sizeof(struct htab_elem) +\n                          round_up(htab->map.key_size, 8);\n        if (percpu)\n                htab->elem_size += sizeof(void *);\n        else\n                htab->elem_size += round_up(htab->map.value_size, 8);\n\nSo storing pptr with 8-byte alignment won't cause any problem and can fix\nkmemleak too.\n\nThe issue can be reproduced with bpf selftest as well:\n  1. Enable CONFIG_DEBUG_KMEMLEAK config\n  2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.\n     The purpose is to keep map available so kmemleak can be detected.\n  3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported."},{"lang":"es","value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige la advertencia de kmemleak para el mapa hash de percpu Vlad Poenaru informó el siguiente problema de kmemleak: objeto sin referencia 0x606fd7c44ac8 (tamaño 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 Una investigación más profunda muestra que la razón se debe a un almacenamiento no alineado de 8 bytes del puntero por CPU en htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr; Tenga en cuenta que la alineación completa de htab_elem es 8 (para x86_64). Si key_size es 4, significa que pptr se almacena en una ubicación que está alineada con 4 bytes pero no con 8 bytes. En mm/kmemleak.c, scan_block() escanea la memoria basándose en un paso de 8 bytes, por lo que no detectará por encima de pptr, por lo que informa la pérdida de memoria. En htab_map_alloc(), ya tenemos 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); Por lo tanto, almacenar pptr con alineación de 8 bytes no causará ningún problema y también puede solucionar la fuga de kmem. El problema también se puede reproducir con la autoprueba de BPF: 1. Habilite la configuración CONFIG_DEBUG_KMEMLEAK. 2. Añada un getchar() antes de skel destroy en test_hash_map() en prog_tests/for_each.c. El objetivo es mantener el mapa disponible para que se pueda detectar la fuga de kmem. 3. Ejecute './test_progs -t for_each/hash_map &' y se debería informar de una fuga de kmem."}],"metrics":{"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6}]},"weaknesses":[{"source":"nvd@nist.gov","type":"Primary","description":[{"lang":"en","value":"CWE-401"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.26","matchCriteriaId":"505F343C-3DE3-4984-A2E0-52BAFF9CC7CE"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.13","versionEndExcluding":"6.14.5","matchCriteriaId":"6B25CA7E-4CD0-46DB-B4EF-13A3516071FB"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/11ba7ce076e5903e7bdc1fd1498979c331b3c286","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/1f1c29aa1934177349c17e3c32e68ec38a7a56df","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/7758e308aeda1038aba1944f7302d34161b3effe","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]}]}}]}