CVE-2025-37807

{"id": "CVE-2025-37807", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2025-05-08T07:15:51.873", "references": [{"url": "https://git.kernel.org/stable/c/11ba7ce076e5903e7bdc1fd1498979c331b3c286", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/1f1c29aa1934177349c17e3c32e68ec38a7a56df", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/7758e308aeda1038aba1944f7302d34161b3effe", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-401"}]}], "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\u00f3 el siguiente problema de kmemleak: objeto sin referencia 0x606fd7c44ac8 (tama\u00f1o 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\u00f3n m\u00e1s profunda muestra que la raz\u00f3n 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\u00f3n completa de htab_elem es 8 (para x86_64). Si key_size es 4, significa que pptr se almacena en una ubicaci\u00f3n que est\u00e1 alineada con 4 bytes pero no con 8 bytes. En mm/kmemleak.c, scan_block() escanea la memoria bas\u00e1ndose en un paso de 8 bytes, por lo que no detectar\u00e1 por encima de pptr, por lo que informa la p\u00e9rdida 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\u00f3n de 8 bytes no causar\u00e1 ning\u00fan problema y tambi\u00e9n puede solucionar la fuga de kmem. El problema tambi\u00e9n se puede reproducir con la autoprueba de BPF: 1. Habilite la configuraci\u00f3n CONFIG_DEBUG_KMEMLEAK. 2. A\u00f1ada 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\u00eda informar de una fuga de kmem."}], "lastModified": "2025-11-10T17:32:35.180", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "505F343C-3DE3-4984-A2E0-52BAFF9CC7CE", "versionEndExcluding": "6.12.26"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "6B25CA7E-4CD0-46DB-B4EF-13A3516071FB", "versionEndExcluding": "6.14.5", "versionStartIncluding": "6.13"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}