CVE-2026-63950 (GCVE-0-2026-63950)

Vulnerability from cvelistv5 – Published: 2026-07-19 14:55 – Updated: 2026-08-05 12:37
VLAI
Title
mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one
Summary
In the Linux kernel, the following vulnerability has been resolved: mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one Initialize nr_pages to 1 at the start of each loop iteration, like folio_referenced_one() does. Without this, nr_pages computed by a previous folio_unmap_pte_batch() call can be reused on a later iteration that does not run folio_unmap_pte_batch() again. mmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call madvise(MADV_FREE), then make the last page device-exclusive via HMM_DMIRROR_EXCLUSIVE. Trigger node reclaim through sysfs. Now, in try_to_unmap_one(), we will first clear the first 15 out of 16 entries mapping the lazyfree folio. This will set nr_pages to 15. In the next pvmw walk, this nr_pages gets reused on a device-exclusive pte, thus potentially corrupting folio refcount/mapcount. At the moment, I have a userspace program which can make the kernel spit out a trace, but the blow up is in folio_referenced_one(), because there are existing bugs in the interaction between device-private and rmap (which too I am investigating). I did a one liner kernel change to avoid going into folio_referenced_one(), and the kernel blows up at folio_remove_rmap_ptes in try_to_unmap_one which is what I wanted. Note that the bug is there not since file folio batching but lazyfree folio batching, since device-exclusive only works for anonymous folios. Userspace visible effect is simply kernel crashing somewhere due to refcount/mapcount corruption.
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: 354dffd29575cdf13154e8fb787322354aa9efc4 , < 0fcc34d0d8fefca4fea349e45c10e3a3d90350eb (git)
Affected: 354dffd29575cdf13154e8fb787322354aa9efc4 , < f611db9b771b2b6775357555d2517af044fca4f0 (git)
Affected: 354dffd29575cdf13154e8fb787322354aa9efc4 , < 3f8968e9cbf95d5d87d32218906cab0b9b9eddbe (git)
guessed Create a notification for this product.
Linux Linux Affected: 6.15
Unaffected: 0 , < 6.15 (semver)
Unaffected: 6.18.35 , ≤ 6.18.* (semver)
Unaffected: 7.0.12 , ≤ 7.0.* (semver)
Unaffected: 7.1 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/rmap.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "0fcc34d0d8fefca4fea349e45c10e3a3d90350eb",
              "status": "affected",
              "version": "354dffd29575cdf13154e8fb787322354aa9efc4",
              "versionType": "git"
            },
            {
              "lessThan": "f611db9b771b2b6775357555d2517af044fca4f0",
              "status": "affected",
              "version": "354dffd29575cdf13154e8fb787322354aa9efc4",
              "versionType": "git"
            },
            {
              "lessThan": "3f8968e9cbf95d5d87d32218906cab0b9b9eddbe",
              "status": "affected",
              "version": "354dffd29575cdf13154e8fb787322354aa9efc4",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/rmap.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.15"
            },
            {
              "lessThan": "6.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.35",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.0.*",
              "status": "unaffected",
              "version": "7.0.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.35",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0.12",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1",
                  "versionStartIncluding": "6.15",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one\n\nInitialize nr_pages to 1 at the start of each loop iteration, like\nfolio_referenced_one() does.\n\nWithout this, nr_pages computed by a previous folio_unmap_pte_batch() call\ncan be reused on a later iteration that does not run\nfolio_unmap_pte_batch() again.\n\nmmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call\nmadvise(MADV_FREE), then make the last page device-exclusive via\nHMM_DMIRROR_EXCLUSIVE.\n\nTrigger node reclaim through sysfs.  Now, in try_to_unmap_one(), we will\nfirst clear the first 15 out of 16 entries mapping the lazyfree folio. \nThis will set nr_pages to 15.  In the next pvmw walk, this nr_pages gets\nreused on a device-exclusive pte, thus potentially corrupting folio\nrefcount/mapcount.\n\nAt the moment, I have a userspace program which can make the kernel spit\nout a trace, but the blow up is in folio_referenced_one(), because there\nare existing bugs in the interaction between device-private and rmap\n(which too I am investigating).  I did a one liner kernel change to avoid\ngoing into folio_referenced_one(), and the kernel blows up at\nfolio_remove_rmap_ptes in try_to_unmap_one which is what I wanted.\n\nNote that the bug is there not since file folio batching but lazyfree\nfolio batching, since device-exclusive only works for anonymous folios.\n\nUserspace visible effect is simply kernel crashing somewhere due to\nrefcount/mapcount corruption."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - Exploitation requires local syscalls (mmap with MAP_DROPPABLE, madvise MADV_FREE/MADV_PAGEOUT, and a device-exclusive ioctl such as HMM_DMIRROR_EXCLUSIVE or GPU SVM) that drive kernel memory reclaim into try_to_unmap_one(); there is no network-facing entry point.\nAC:L - The reporter provides a deterministic userspace reproducer and the attacker fully controls the memory layout (64K lazyfree large folio with one device-exclusive PTE) and reclaim triggering; no race or layout condition outside attacker control is required beyond having DEVICE_PRIVATE/THP enabled.\nPR:L - A normal unprivileged local process can perform the required mmap/madvise sequence and trigger reclaim via MADV_PAGEOUT or memory pressure; marking a page device-exclusive only needs access to a GPU render node or hmm_dmirror test device, which is routinely granted to unprivileged users on GPU-equipped systems.\nUI:N - No victim interaction is required; the attacker runs the exploit sequence in their own process to corrupt folio refcount/mapcount during reclaim.\nS:U - Impact is confined to kernel memory management within the same security authority; this is standard kernel memory corruption/privilege-escalation territory, not a VM escape or cross-authority boundary bypass.\nC:H - Stale nr_pages causes folio_remove_rmap_ptes() and folio_put_refs() to operate on the wrong page count, corrupting mapcount and refcount; the author confirms refcount/mapcount corruption and this class of bug can yield use-after-free with arbitrary read primitives.\nI:H - Incorrect multi-page rmap removal and reference dropping on a single device-exclusive PTE is exploitable memory corruption that can lead to use-after-free and arbitrary kernel write/control-flow hijack, not merely a bounded modification.\nA:H - The fix commit and reporter explicitly state the userspace-visible effect is kernel crashes (oops/panic) from refcount/mapcount corruption, observed at folio_remove_rmap_ptes in try_to_unmap_one."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T12:37:35.244Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/0fcc34d0d8fefca4fea349e45c10e3a3d90350eb"
        },
        {
          "url": "https://git.kernel.org/stable/c/f611db9b771b2b6775357555d2517af044fca4f0"
        },
        {
          "url": "https://git.kernel.org/stable/c/3f8968e9cbf95d5d87d32218906cab0b9b9eddbe"
        }
      ],
      "title": "mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-63950",
    "datePublished": "2026-07-19T14:55:43.404Z",
    "dateReserved": "2026-07-19T07:54:57.023Z",
    "dateUpdated": "2026-08-05T12:37:35.244Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-63950",
      "date": "2026-09-22",
      "epss": "0.00166",
      "percentile": "0.06293"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "mm/rmap.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "0fcc34d0d8fefca4fea349e45c10e3a3d90350eb",
                    "status": "affected",
                    "version": "354dffd29575cdf13154e8fb787322354aa9efc4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "f611db9b771b2b6775357555d2517af044fca4f0",
                    "status": "affected",
                    "version": "354dffd29575cdf13154e8fb787322354aa9efc4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "3f8968e9cbf95d5d87d32218906cab0b9b9eddbe",
                    "status": "affected",
                    "version": "354dffd29575cdf13154e8fb787322354aa9efc4",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "mm/rmap.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "6.15"
                  },
                  {
                    "lessThan": "6.15",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.35",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.0.*",
                    "status": "unaffected",
                    "version": "7.0.12",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.1",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one\n\nInitialize nr_pages to 1 at the start of each loop iteration, like\nfolio_referenced_one() does.\n\nWithout this, nr_pages computed by a previous folio_unmap_pte_batch() call\ncan be reused on a later iteration that does not run\nfolio_unmap_pte_batch() again.\n\nmmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call\nmadvise(MADV_FREE), then make the last page device-exclusive via\nHMM_DMIRROR_EXCLUSIVE.\n\nTrigger node reclaim through sysfs.  Now, in try_to_unmap_one(), we will\nfirst clear the first 15 out of 16 entries mapping the lazyfree folio. \nThis will set nr_pages to 15.  In the next pvmw walk, this nr_pages gets\nreused on a device-exclusive pte, thus potentially corrupting folio\nrefcount/mapcount.\n\nAt the moment, I have a userspace program which can make the kernel spit\nout a trace, but the blow up is in folio_referenced_one(), because there\nare existing bugs in the interaction between device-private and rmap\n(which too I am investigating).  I did a one liner kernel change to avoid\ngoing into folio_referenced_one(), and the kernel blows up at\nfolio_remove_rmap_ptes in try_to_unmap_one which is what I wanted.\n\nNote that the bug is there not since file folio batching but lazyfree\nfolio batching, since device-exclusive only works for anonymous folios.\n\nUserspace visible effect is simply kernel crashing somewhere due to\nrefcount/mapcount corruption."
          }
        ],
        "id": "CVE-2026-63950",
        "lastModified": "2026-07-27T17:44:23.777",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-07-19T16:17:13.730",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/0fcc34d0d8fefca4fea349e45c10e3a3d90350eb"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/3f8968e9cbf95d5d87d32218906cab0b9b9eddbe"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/f611db9b771b2b6775357555d2517af044fca4f0"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Awaiting Analysis"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Important",
      "current_release_date": "2026-07-21T22:21:45+00:00",
      "cve": "CVE-2026-63950",
      "id": "CVE-2026-63950",
      "initial_release_date": "2026-07-19T00:00:00+00:00",
      "product_status:known_affected": "76",
      "product_status:known_not_affected": "184",
      "product_status:under_investigation": "14",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-63950.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "important",
      "current_release_date": "2026-07-21T13:02:54Z",
      "cve": "CVE-2026-63950",
      "id": "CVE-2026-63950",
      "initial_release_date": "2026-07-21T13:02:54Z",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-63950",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-63950.json",
      "version": "2"
    }
  }
}



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.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.