Description
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.
Published: 2026-07-19
Score: 7.8 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability resides in the Linux kernel’s memory mapping subsystem: the loop variable nr_pages is not re‑initialized at the start of each iteration of try_to_unmap_one, allowing a value computed by a prior folio_unmap_pte_batch() call to be mistakenly reused. When the kernel subsequently processes a device‑exclusive page, this stale nr_pages value can corrupt folio reference or map counters, which leads to a crash. The bug is exposed by mapping a 64 KiB anonymous region with MAP_DROPPABLE, advising MADV_FREE, marking the last page device‑exclusive, and then triggering node reclaim via sysfs.

Affected Systems

All Linux kernel builds that include the mm/rmap code path are affected. This spans the generic Linux product across all supported architectures. Systems running an unpatched kernel are vulnerable until a patch is applied.

Risk and Exploitability

The CVSS score is 7.8, indicating a high severity vulnerability. The EPSS score of less than 1 % shows a very low likelihood of exploitation in the wild. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires a complex, multi‑step memory‑mapping sequence and the activation of node reclaim, which limits the attack surface to a local context with significant technical effort. Successful execution would result in kernel crashes, leading to a denial of service for affected processes or the entire system.

Generated by OpenCVE AI on August 3, 2026 at 01:58 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest vendor patch for the rmap nr_pages initialization bug from the upstream kernel release.
  • If patching is not yet available, avoid using MAP_DROPPABLE in combination with HMM_DMIRROR_EXCLUSIVE during the vulnerable period.
  • Monitor for system crashes or kernel panics related to rmap handling and reboot into a trusted kernel state if such events occur.
  • Keep the kernel updated to a version that contains the fix once it becomes available.

Generated by OpenCVE AI on August 3, 2026 at 01:58 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Ubuntu USN Ubuntu USN USN-8593-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8603-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8618-1 Linux kernel vulnerabilities
History

Wed, 29 Jul 2026 01:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Wed, 22 Jul 2026 18:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Wed, 22 Jul 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-911
References
Metrics threat_severity

None

threat_severity

Important


Mon, 20 Jul 2026 14:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}


Sun, 19 Jul 2026 15:30:00 +0000

Type Values Removed Values Added
Description 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.
Title mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-05T12:37:35.244Z

Reserved: 2026-07-19T07:54:57.023Z

Link: CVE-2026-63950

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

Severity : Important

Publid Date: 2026-07-19T00:00:00Z

Links: CVE-2026-63950 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-03T02:00:15Z

Weaknesses
  • CWE-911

    Improper Update of Reference Count