CVE-2025-37807 (GCVE-0-2025-37807)

Vulnerability from cvelistv5 – Published: 2025-05-08 06:26 – Updated: 2026-05-11 21:15
VLAI
Title
bpf: Fix kmemleak warning for percpu hashmap
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.
Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 824bd0ce6c7c43a9e1e210abf124958e54d88342 , < 7758e308aeda1038aba1944f7302d34161b3effe (git)
Affected: 824bd0ce6c7c43a9e1e210abf124958e54d88342 , < 1f1c29aa1934177349c17e3c32e68ec38a7a56df (git)
Affected: 824bd0ce6c7c43a9e1e210abf124958e54d88342 , < 11ba7ce076e5903e7bdc1fd1498979c331b3c286 (git)
Create a notification for this product.
Linux Linux Affected: 4.6
Unaffected: 0 , < 4.6 (semver)
Unaffected: 6.12.26 , ≤ 6.12.* (semver)
Unaffected: 6.14.5 , ≤ 6.14.* (semver)
Unaffected: 6.15 , ≤ * (original_commit_for_fix)
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": "824bd0ce6c7c43a9e1e210abf124958e54d88342",
              "versionType": "git"
            },
            {
              "lessThan": "1f1c29aa1934177349c17e3c32e68ec38a7a56df",
              "status": "affected",
              "version": "824bd0ce6c7c43a9e1e210abf124958e54d88342",
              "versionType": "git"
            },
            {
              "lessThan": "11ba7ce076e5903e7bdc1fd1498979c331b3c286",
              "status": "affected",
              "version": "824bd0ce6c7c43a9e1e210abf124958e54d88342",
              "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": [
            {
              "status": "affected",
              "version": "4.6"
            },
            {
              "lessThan": "4.6",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "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",
                  "versionStartIncluding": "4.6",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.14.5",
                  "versionStartIncluding": "4.6",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15",
                  "versionStartIncluding": "4.6",
                  "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": "2026-05-11T21:15:31.586Z",
        "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": "2026-05-11T21:15:31.586Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-37807",
      "date": "2026-06-06",
      "epss": "0.00042",
      "percentile": "0.13211"
    },
    "nvd": "{\"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-\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\":{\"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\"]}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.