CVE-2026-98939 in Linux
Summary
by MITRE • 10/23/2026
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. ]
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel vulnerability identified in this context involves a potential deadlock scenario within the x86 memory management subsystem, specifically triggered during page table operations involving huge virtual mappings and GPU driver interactions. The root cause lies in an interaction between the kswapd thread, which handles memory reclaim for the TTM (Translation Table Maps) page pool used by discrete GPUs, and the kernel's mmap locking mechanisms. A recent commit introduced a requirement to hold the mmap_read_lock during certain kernel page protection modifications via change_page_attr_set_clr. This lock is also held when allocating pages for huge vmap operations using GFP_KERNEL allocations. Since memory reclaim can trigger under these allocation conditions, it creates a circular dependency where kswapd holds pool_shrink_rwsem while attempting to acquire mmap_lock, and other paths hold mmap_lock while triggering fs_reclaim which eventually leads back to acquiring pool_shrink_rwsem. This locking cycle results in lockdep warnings indicating possible deadlocks that can stall system operations or cause hangs under specific workload conditions involving GPU memory management and kernel page attribute changes.
The technical flaw centers on an unnecessary PMD (Page Middle Directory) page copy operation performed during the freeing of huge vmap structures. The original code attempted to prevent hardware from setting the Accessed bit in page table entries that were unreachable by hardware, a precaution deemed redundant as modern systems handle this correctly without such intervention. This copying mechanism required additional allocations and complex locking interactions that exacerbated the deadlock potential. By removing the PMD copy operation, the vulnerability is addressed through simplification of the memory management path. The fix involves detaching the original PMD page at the PUD (Page Upper Directory) level, flushing mid-level caches to ensure consistency, and freeing the PTE (Page Table Entry) tables directly from the detached PMD page without requiring new allocations that would trigger reclaim cycles under held locks.
From a security perspective, this vulnerability aligns with CWE-833 regarding Locking Incorrectly or Redundantly, as it involves improper handling of synchronization primitives leading to potential denial of service through deadlock conditions. The ATT&CK framework does not directly classify kernel internal deadlocks as attack vectors unless exploited for privilege escalation, but the underlying issue reflects poor resource management practices that could be leveraged in localized denial-of-service scenarios against systems with discrete GPUs and heavy memory pressure. The impact is primarily operational stability rather than direct data compromise or unauthorized access, though prolonged system hangs can indirectly affect availability of critical services running on affected kernels.
Mitigation strategies include applying the upstream kernel patch that removes the unnecessary PMD copy logic and adjusts the locking hierarchy to prevent circular dependencies during page table teardown operations. System administrators should ensure their Linux distributions are updated with versions containing this fix, particularly those targeting x86 architectures with discrete GPU support using TTM drivers. For environments unable to immediately update kernels, monitoring for lockdep splats in dmesg logs can help identify affected systems before they experience functional degradation due to deadlocks during memory-intensive operations involving GPU buffers or large virtual mappings.