CVE-2025-37807 (GCVE-0-2025-37807)
Vulnerability from cvelistv5
Published
2025-05-08 06:26
Modified
2025-05-26 05:21
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
Impacted products
Vendor Product Version
Linux Linux Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Version: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/hashtab.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "7758e308aeda1038aba1944f7302d34161b3effe",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "1f1c29aa1934177349c17e3c32e68ec38a7a56df",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "11ba7ce076e5903e7bdc1fd1498979c331b3c286",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "kernel/bpf/hashtab.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.26",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.14.*",
              "status": "unaffected",
              "version": "6.14.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.15",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.26",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.14.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-26T05:21:16.806Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/7758e308aeda1038aba1944f7302d34161b3effe"
        },
        {
          "url": "https://git.kernel.org/stable/c/1f1c29aa1934177349c17e3c32e68ec38a7a56df"
        },
        {
          "url": "https://git.kernel.org/stable/c/11ba7ce076e5903e7bdc1fd1498979c331b3c286"
        }
      ],
      "title": "bpf: Fix kmemleak warning for percpu hashmap",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-37807",
    "datePublished": "2025-05-08T06:26:06.296Z",
    "dateReserved": "2025-04-16T04:51:23.942Z",
    "dateUpdated": "2025-05-26T05:21:16.806Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-37807\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-05-08T07:15:51.873\",\"lastModified\":\"2025-05-08T14:39:09.683\",\"vulnStatus\":\"Awaiting Analysis\",\"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.\"}],\"metrics\":{},\"references\":[{\"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\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


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.