CVE-2025-38207 (GCVE-0-2025-38207)

Vulnerability from cvelistv5 – Published: 2025-07-04 13:37 – Updated: 2026-05-11 21:23
VLAI
Title
mm: fix uprobe pte be overwritten when expanding vma
Summary
In the Linux kernel, the following vulnerability has been resolved: mm: fix uprobe pte be overwritten when expanding vma Patch series "Fix uprobe pte be overwritten when expanding vma". This patch (of 4): We encountered a BUG alert triggered by Syzkaller as follows: BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1 And we can reproduce it with the following steps: 1. register uprobe on file at zero offset 2. mmap the file at zero offset: addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. mremap part of vma1 to new vma2: addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); 4. mremap back to orig addr1: mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2 with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1 to vma2, then unmap the vma1 range [addr1, addr1 + 4096]. In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096, addr1 + 8192] still maps the file, it will take vma_merge_new_range to expand the range, and then do uprobe_mmap in vma_complete. Since the merged vma pgoff is also zero offset, it will install uprobe anon page to the merged vma. However, the upcomming move_page_tables step, which use set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite the newly uprobe pte in the merged vma, and lead that pte to be orphan. Since the uprobe pte will be remapped to the merged vma, we can remove the unnecessary uprobe_mmap upon merged vma. This problem was first found in linux-6.6.y and also exists in the community syzkaller: https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/
Severity
No CVSS data available.
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 2b144498350860b6ee9dc57ff27a93ad488de5dc , < 58b83b9a9a929611a2a2e7d88f45cb0d786b7ee0 (git)
Affected: 2b144498350860b6ee9dc57ff27a93ad488de5dc , < 2b12d06c37fd3a394376f42f026a7478d826ed63 (git)
Create a notification for this product.
Linux Linux Affected: 3.5
Unaffected: 0 , < 3.5 (semver)
Unaffected: 6.15.4 , ≤ 6.15.* (semver)
Unaffected: 6.16 , ≤ * (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": [
            "mm/vma.c",
            "mm/vma.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "58b83b9a9a929611a2a2e7d88f45cb0d786b7ee0",
              "status": "affected",
              "version": "2b144498350860b6ee9dc57ff27a93ad488de5dc",
              "versionType": "git"
            },
            {
              "lessThan": "2b12d06c37fd3a394376f42f026a7478d826ed63",
              "status": "affected",
              "version": "2b144498350860b6ee9dc57ff27a93ad488de5dc",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/vma.c",
            "mm/vma.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "3.5"
            },
            {
              "lessThan": "3.5",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.15.*",
              "status": "unaffected",
              "version": "6.15.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.16",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15.4",
                  "versionStartIncluding": "3.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.16",
                  "versionStartIncluding": "3.5",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix uprobe pte be overwritten when expanding vma\n\nPatch series \"Fix uprobe pte be overwritten when expanding vma\".\n\n\nThis patch (of 4):\n\nWe encountered a BUG alert triggered by Syzkaller as follows:\n   BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1\n\nAnd we can reproduce it with the following steps:\n1. register uprobe on file at zero offset\n2. mmap the file at zero offset:\n   addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0);\n3. mremap part of vma1 to new vma2:\n   addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE);\n4. mremap back to orig addr1:\n   mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);\n\nIn step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2\nwith range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1\nto vma2, then unmap the vma1 range [addr1, addr1 + 4096].\n\nIn step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the\naddr range [addr1, addr1 + 4096].  Since the addr range [addr1 + 4096,\naddr1 + 8192] still maps the file, it will take vma_merge_new_range to\nexpand the range, and then do uprobe_mmap in vma_complete.  Since the\nmerged vma pgoff is also zero offset, it will install uprobe anon page to\nthe merged vma.  However, the upcomming move_page_tables step, which use\nset_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite\nthe newly uprobe pte in the merged vma, and lead that pte to be orphan.\n\nSince the uprobe pte will be remapped to the merged vma, we can remove the\nunnecessary uprobe_mmap upon merged vma.\n\nThis problem was first found in linux-6.6.y and also exists in the\ncommunity syzkaller:\nhttps://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T21:23:19.597Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/58b83b9a9a929611a2a2e7d88f45cb0d786b7ee0"
        },
        {
          "url": "https://git.kernel.org/stable/c/2b12d06c37fd3a394376f42f026a7478d826ed63"
        }
      ],
      "title": "mm: fix uprobe pte be overwritten when expanding vma",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-38207",
    "datePublished": "2025-07-04T13:37:27.508Z",
    "dateReserved": "2025-04-16T04:51:23.994Z",
    "dateUpdated": "2026-05-11T21:23:19.597Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-38207",
      "date": "2026-05-26",
      "epss": "0.00078",
      "percentile": "0.22984"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-38207\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-07-04T14:15:28.823\",\"lastModified\":\"2025-11-18T17:07:12.037\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm: fix uprobe pte be overwritten when expanding vma\\n\\nPatch series \\\"Fix uprobe pte be overwritten when expanding vma\\\".\\n\\n\\nThis patch (of 4):\\n\\nWe encountered a BUG alert triggered by Syzkaller as follows:\\n   BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1\\n\\nAnd we can reproduce it with the following steps:\\n1. register uprobe on file at zero offset\\n2. mmap the file at zero offset:\\n   addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0);\\n3. mremap part of vma1 to new vma2:\\n   addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE);\\n4. mremap back to orig addr1:\\n   mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);\\n\\nIn step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2\\nwith range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1\\nto vma2, then unmap the vma1 range [addr1, addr1 + 4096].\\n\\nIn step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the\\naddr range [addr1, addr1 + 4096].  Since the addr range [addr1 + 4096,\\naddr1 + 8192] still maps the file, it will take vma_merge_new_range to\\nexpand the range, and then do uprobe_mmap in vma_complete.  Since the\\nmerged vma pgoff is also zero offset, it will install uprobe anon page to\\nthe merged vma.  However, the upcomming move_page_tables step, which use\\nset_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite\\nthe newly uprobe pte in the merged vma, and lead that pte to be orphan.\\n\\nSince the uprobe pte will be remapped to the merged vma, we can remove the\\nunnecessary uprobe_mmap upon merged vma.\\n\\nThis problem was first found in linux-6.6.y and also exists in the\\ncommunity syzkaller:\\nhttps://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: se corrige la sobrescritura del archivo uprobe al expandir vma. Serie de parches \\\"Corregir la sobrescritura del archivo uprobe al expandir vma\\\". Este parche (de 4): Se detect\u00f3 una alerta de error generada por Syzkaller: Error: Estado incorrecto del contador RSS mm:00000000b4a60fca tipo:MM_ANONPAGES val:1. Se puede reproducir con los siguientes pasos: 1. Registrar uprobe en el archivo con desplazamiento cero. 2. Asignar el archivo con mmap en el desplazamiento cero: addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. Asignar con mremap parte de vma1 al nuevo vma2: addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); 4. mremap de vuelta a la direcci\u00f3n original 1: mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); En el paso 3, el rango vma1 [addr1, addr1 + 4096] se reasignar\u00e1 a la nueva vma2 con rango [addr2, addr2 + 8192] y se reasignar\u00e1 la p\u00e1gina uprobe anon de vma1 a vma2, luego desasignar\u00e1 el rango vma1 [addr1, addr1 + 4096]. En el paso 4, el rango vma2 [addr2, addr2 + 4096] se reasignar\u00e1 de nuevo al rango addr [addr1, addr1 + 4096]. Dado que el rango de direcciones [addr1 + 4096, addr1 + 8192] a\u00fan asigna el archivo, se requerir\u00e1 vma_merge_new_range para expandir el rango y luego ejecutar uprobe_mmap en vma_complete. Dado que el desplazamiento de la p\u00e1gina de la vma fusionada tambi\u00e9n tiene desplazamiento cero, se instalar\u00e1 uprobe anon page en la vma fusionada. Sin embargo, el siguiente paso `move_page_tables`, que usa `set_pte_at` para reasignar la pte de uprobe vma2 a la vma fusionada, sobrescribir\u00e1 la nueva pte de uprobe en la vma fusionada y la dejar\u00e1 hu\u00e9rfana. Dado que la pte de uprobe se reasignar\u00e1 a la vma fusionada, podemos eliminar uprobe_mmap innecesario al fusionar la vma. Este problema se encontr\u00f3 por primera vez en linux-6.6.y y tambi\u00e9n existe en la comunidad syzkaller: https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/\"}],\"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:H/A:N\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"3.5\",\"versionEndExcluding\":\"6.15.4\",\"matchCriteriaId\":\"70F17898-FFE8-46CE-936C-A820CAF98A94\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/2b12d06c37fd3a394376f42f026a7478d826ed63\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/58b83b9a9a929611a2a2e7d88f45cb0d786b7ee0\",\"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.