fkie_cve-2025-37807
Vulnerability from fkie_nvd
Published
2025-05-08 07:15
Modified
2025-05-08 14:39
Severity ?
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/11ba7ce076e5903e7bdc1fd1498979c331b3c286
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1f1c29aa1934177349c17e3c32e68ec38a7a56df
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7758e308aeda1038aba1944f7302d34161b3effe
Impacted products
Vendor Product Version


To clipboard 

{
  "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-\u003ekey + 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\u0027t detect above pptr, hence reporting the memory\nleak.\n\nIn htab_map_alloc(), we already have\n\n        htab-\u003eelem_size = sizeof(struct htab_elem) +\n                          round_up(htab-\u003emap.key_size, 8);\n        if (percpu)\n                htab-\u003eelem_size += sizeof(void *);\n        else\n                htab-\u003eelem_size += round_up(htab-\u003emap.value_size, 8);\n\nSo storing pptr with 8-byte alignment won\u0027t 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 \u0027./test_progs -t for_each/hash_map \u0026\u0027 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-\u0026gt;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-\u0026gt;elem_size = sizeof(struct htab_elem) + round_up(htab-\u0026gt;map.key_size, 8); if (percpu) htab-\u0026gt;elem_size += sizeof(void *); else htab-\u0026gt;elem_size += round_up(htab-\u0026gt;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 \u0027./test_progs -t for_each/hash_map \u0026amp;\u0027 y se deber\u00eda informar de una fuga de kmem."
    }
  ],
  "id": "CVE-2025-37807",
  "lastModified": "2025-05-08T14:39:09.683",
  "metrics": {},
  "published": "2025-05-08T07:15:51.873",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/11ba7ce076e5903e7bdc1fd1498979c331b3c286"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1f1c29aa1934177349c17e3c32e68ec38a7a56df"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7758e308aeda1038aba1944f7302d34161b3effe"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.