Read the docs
TI-2026-38242 Aliases CVE-2026-53155GHSA-7xgx-c4jr-vfq9

mm/huge_memory: use correct flags for device private PMD entry

Priority LOW 24Published · Updated

Key facts

Attack vector
Local
Privileges required
Low
User interaction
None
Attack complexity
Low
Impact type
—
Confidentiality · integrity · availability
None · None · High
Fix status
Fixed

Attack profile from CVSS 3.1 · NVD. Fix status from CNA.

Summary

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: 1. The test faults in a range then migrates it such that a device-private THP range is established. 2. 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). 3. The parent forks and the PMD entries are set to device-private read only entries, entire_mapcount=2, softdirty still set. 4. [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. 5. 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. 6. [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.

Why it matters now

EPSS 0.00143 3rd percentileScored 2026-11-07
Fix Fixed Linux (Linux): 7.0.13, 7.1

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
LinuxLinux6.19 and later7.0.13, 7.1Patch availableCNA
  • Linux VendorLinux Affected 6.19 and later Fixed in 7.0.13, 7.1 Patch available CNA

CPE configurations NVD · 8

CPEVersionsRoleVendor
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*6.19 to before 7.0.13VulnerableLinux
cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*7.1 rc1VulnerableLinux
cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*7.1 rc2VulnerableLinux
cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:*7.1 rc3VulnerableLinux
cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:*7.1 rc4VulnerableLinux
cpe:2.3:o:linux:linux_kernel:7.1:rc5:*:*:*:*:*:*7.1 rc5VulnerableLinux
cpe:2.3:o:linux:linux_kernel:7.1:rc6:*:*:*:*:*:*7.1 rc6VulnerableLinux
cpe:2.3:o:linux:linux_kernel:7.1:rc7:*:*:*:*:*:*7.1 rc7VulnerableLinux
  • cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* Versions 6.19 to before 7.0.13 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:* Versions 7.1 rc1 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:* Versions 7.1 rc2 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:* Versions 7.1 rc3 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:* Versions 7.1 rc4 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:7.1:rc5:*:*:*:*:*:* Versions 7.1 rc5 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:7.1:rc6:*:*:*:*:*:* Versions 7.1 rc6 Vulnerable ·Linux
  • cpe:2.3:o:linux:linux_kernel:7.1:rc7:*:*:*:*:*:* Versions 7.1 rc7 Vulnerable ·Linux

Remediation

  • Fix · CNA Linux (Linux) Fixed in 7.0.13, 7.1

Vendor assessments

Red Hat

Red Hat's page for this CVE →

Not affected: 5 products
  • Red Hat Enterprise Linux 10
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 9

Timeline

  1. 2026-10-02 Threatist record created from CVE-2026-53155
  2. 2026-10-03 Alias added: GHSA-7xgx-c4jr-vfq9

References

  • TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
  • TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
  • TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
  • TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
  • TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
  • TI-2021-05514 Heap Out-Of-Bounds Write in Netfilter IP6T_SO_SET_REPLACE KEVCVSS 3.1HIGH 8.3
See all 15278 →

Sources