Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
AC:H reflects the niche hardware and CONFIG_MEM_SOFT_DIRTY prerequisite; AV:L and PR:L are unambiguous from the local, low-privilege execution requirement.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
6DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: use correct flags for device private PMD entry
Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries") updated set_pmd_migration_entry() to use pmdp_huge_get_and_clear() in the softleaf case, but made no further adjustments to the function itself.
Therefore this function continues to incorrectly use pmd_write(), pmd_soft_dirty() and pmd_uffd_wp() to determine whether the installed migration entry should be marked writable, softdirty or uffd-wp respectively.
Whilst all are incorrect, the most problematic of these is pmd_write(), as this can lead to corrupted rmap state.
On x86-64 _PAGE_SWP_SOFT_DIRTY is aliased to _PAGE_RW. So calling pmd_write() on a softleaf will return the softdirty state encoded in the entry, assuming CONFIG_MEM_SOFT_DIRTY was enabled.
This was observed when running the hmm.hmm_device_private.anon_write_child selftest:
- The test faults in a range then migrates it such that a device-private
THP range is established.
- The parent then migrates it to a device-private writable PMD entry whose
folio is entirely AnonExclusive with entire_mapcount=1, softdirty set (accidentally correct write state).
- The parent forks and the PMD entries are set to device-private read only
entries, entire_mapcount=2, softdirty still set.
- [BUG] The child writes to the range then migrates to RAM - intending to
install non-writable migration entries - but replacing parent and child PMD mappings with WRITABLE entries due to misinterpreting the softdirty bit.
- In remove_migration_pmd(), if !softleaf_is_migration_read(entry) we
set the RMAP_EXCLUSIVE flag when calling folio_add_anon_rmap_pmd() for both parent and child, which are therefore AnonExclusive.
- [SPLAT] Child sets migrated folio entire_mapcount=1, parent sets
entire_mapcount=2 and we end up with an AnonExclusive folio with entire_mapcount=2! Assert fires in __folio_add_anon_rmap():
VM_WARN_ON_FOLIO(folio_test_large(folio) && folio_entire_mapcount(folio) > 1 && PageAnonExclusive(cur_page), folio)
This patch fixes the issue by correctly referencing the softleaf entry fields for writable, softdirty and uffd-wp in set_pmd_migration_entry().
It also only updates A/D flags if the entry is present as these are otherwise not meaningful for a softleaf entry.
This patch also flips the if (!present) { ... } else { ... } logic in set_pmd_migration_entry() so it is easier to understand, and adds some comments to make things clearer.
I was able to bisect this to commit 775465fd26a3 ("lib/test_hmm: add zone device private THP test infrastructure") which first exposes this bug as it was the commit that permitted test_hmm to generate the test.
However commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries") is the commit that actually enabled this behaviour.
AnalysisAI
Corrupted reverse-mapping (rmap) state in the Linux kernel's mm/huge_memory subsystem crashes or destabilizes affected systems through a flag misinterpretation in set_pmd_migration_entry() for device-private PMD entries. On x86-64 with CONFIG_MEM_SOFT_DIRTY enabled, the function incorrectly reads the softdirty bit as a write-permission flag - because _PAGE_SWP_SOFT_DIRTY aliases _PAGE_RW - causing migration entries to be marked writable when they should be read-only, ultimately triggering a VM_WARN assertion in __folio_add_anon_rmap() when an AnonExclusive folio reaches entire_mapcount=2. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires all of the following: (1) x86-64 architecture specifically, due to _PAGE_SWP_SOFT_DIRTY aliasing _PAGE_RW in the page table entry bit layout; (2) kernel compiled with CONFIG_MEM_SOFT_DIRTY enabled; (3) kernel compiled with HMM (Heterogeneous Memory Management) device-private THP support; (4) physical hardware with device-private memory accessible via the HMM subsystem (typically a discrete GPU with its own device DRAM and an HMM-aware driver); (5) a specific userspace code sequence: establish device-private THP mappings, fork a child process, have the child write to the range and trigger migration to system RAM. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The provided CVSS 5.5 (Medium, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) accurately reflects local-only exploitation requiring low privilege, with a high availability impact limited to the vulnerable system. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A local user process with access to HMM-capable device memory (e.g., a GPU driver exposing device-private pages via the HMM subsystem) establishes a device-private THP mapping, forks a child process, and then causes the child to write to the shared memory range and trigger migration back to system RAM. The kernel misreads the softdirty bit in the device-private PMD entry as a write-permission flag, installs writable migration entries where read-only entries were intended, and then sets RMAP_EXCLUSIVE on both parent and child folios in remove_migration_pmd(), resulting in an AnonExclusive folio with entire_mapcount=2 and a VM_WARN assertion that crashes the process or destabilizes kernel memory accounting. … |
| Remediation | Apply the stable-tree fix commits available at https://git.kernel.org/stable/c/43e7f189769c512c843184a8a5892ac779a6bd90 (one stable branch) and https://git.kernel.org/stable/c/d7251c8d3f7cea76543abac6cf4ed15582c10846 (second stable branch). … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-39246
GHSA-7xgx-c4jr-vfq9