CVE-2026-98939

x86/mm: Drop unnecessary PMD page copy when freeing

State
Published
Severity
Not scored
Published
Oct 23, 2026
Updated
Oct 23, 2026
Reserved
Sep 25, 2026

Read the record on cve.org

Description

In the Linux kernel, the following vulnerability has been resolved:

x86/mm: Drop unnecessary PMD page copy when freeing

On a box with a discrete GPU, lockdep reports a possible deadlock as soon as kswapd shrinks the TTM page pool. The immediate cause is an x86 commit that added an mmap_read_lock() to kernel page protection munging code.

The huge vmap code holds the same lock over a GFP_KERNEL allocation, which is a no-no now that reclaim can take it. That allocation is in a page table *free* path and ends up being for dubious purposes[1]. Basically, it tries to avoid hardware setting Accessed=1 in page table entries that are unreachable by the hardware, a non-issue.

Remove the PMD copy. Detach the original PMD page at the PUD, flush the mid-level caches, and free the PTE tables straight from the detached PMD page. With no allocation left, the locking issue is gone.

Lockdep splat/analysis:

WARNING: possible circular locking dependency detected 7.3.0-rc3-f6e7b42bf05b+ #183 Tainted: G U ------------------------------------------------------ kswapd0/269 is trying to acquire lock: ((init_mm).mmap_lock){++++}-{4:4}, at: change_page_attr_set_clr+0x29a/0x4a0 but task is already holding lock: (pool_shrink_rwsem){.+.+}-{4:4}, at: ttm_pool_shrink+0xb2/0x330 [ttm] Chain exists of: (init_mm).mmap_lock --> fs_reclaim --> pool_shrink_rwsem

The cycle is built from three edges:

1) pool_shrink_rwsem -> (init_mm).mmap_lock

The TTM shrinker restores the caching attribute of every page it frees, while holding pool_shrink_rwsem:

ttm_pool_shrink() -> ttm_pool_dispose_list() -> ttm_pool_free_page() -> set_pages_wb() -> change_page_attr_set_clr() [ init_mm mmap read lock ]

2) fs_reclaim -> pool_shrink_rwsem

The same shrinker, called from reclaim.

3) (init_mm).mmap_lock -> fs_reclaim

ioremap() installing a huge PUD mapping over an existing PMD table:

ioremap_page_range() -> vmap_range_noflush() -> vmap_try_huge_pud() [ init_mm mmap read lock ] -> pud_free_pmd_page() -> __get_free_page(GFP_KERNEL) [ enters reclaim ]

[ dhansen: Lots of changelog munging/trimming and merged comments from my version of the fix. ]

Scores

The record has no CVSS score.

Weaknesses

The record names no weakness.

Affected Products

ProductVersions
LinuxLinux
  • e21a9ea81426a85fdb0cdcfcc99d5d9c16b402ab to before d3c2d2692bdf4af94bb27bc7a3aa0a348a567606Affected
  • cc73b2043d106b467accd38e9b1fc09e0607c056 to before f38c57a28ebbd057471573e39555d5aa11ab03cfAffected
  • d5d8b8662e6e5a565b47a0388640e88402f23274 to before e3ee38c1bc0b11a8d3e63dce7050759b61864286Affected
LinuxLinux
  • 6.18.53 to before 6.18.56Affected
  • 7.2.7 to before 7.2.10Affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.