x86/mm: Drop unnecessary PMD page copy when freeing
Summary
| CVE | CVE-2026-98939 |
|---|
| State | PUBLISHED |
|---|
| Assigner | Linux |
|---|
| Source Priority | CVE Program / NVD first with legacy fallback |
|---|
| Published | 2026-10-23 13:17:14 UTC |
|---|
| Updated | 2026-10-23 13:17:14 UTC |
|---|
| 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. ] |
|---|
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|
| CNA |
Linux |
Linux |
affected e21a9ea81426a85fdb0cdcfcc99d5d9c16b402ab d3c2d2692bdf4af94bb27bc7a3aa0a348a567606 git |
Not specified |
| CNA |
Linux |
Linux |
affected cc73b2043d106b467accd38e9b1fc09e0607c056 f38c57a28ebbd057471573e39555d5aa11ab03cf git |
Not specified |
| CNA |
Linux |
Linux |
affected d5d8b8662e6e5a565b47a0388640e88402f23274 e3ee38c1bc0b11a8d3e63dce7050759b61864286 git |
Not specified |
| CNA |
Linux |
Linux |
affected 6.18.53 6.18.56 semver |
Not specified |
| CNA |
Linux |
Linux |
affected 7.2.7 7.2.10 semver |
Not specified |
References
| Reference | Source | Link | Tags |
|---|
| git.kernel.org/stable/c/e3ee38c1bc0b11a8d3e63dce7050759b61864286 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/d3c2d2692bdf4af94bb27bc7a3aa0a348a567606 |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| git.kernel.org/stable/c/f38c57a28ebbd057471573e39555d5aa11ab03cf |
416baaa9-dc9f-4396-8d5f-8c081fb06d67 |
git.kernel.org |
|
| CVE Program record |
CVE.ORG |
www.cve.org |
canonical |
| NVD vulnerability detail |
NVD |
nvd.nist.gov |
canonical, analysis |
No vendor comments have been submitted for this CVE.
There are currently no legacy QID mappings associated with this CVE.