CVE-2026-98939
Received Received - Intake

Linux Kernel Memory Management Deadlock in x86/mm

Vulnerability report for CVE-2026-98939, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-10-23

Last updated on: 2026-10-23

Assigner: kernel.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. ]

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-10-23
Last Modified
2026-10-23
Generated
2026-10-23
EPSS Evaluated
N/A
NVD
EUVD

Affected Vendors & Products

Showing 5 associated CPEs
Vendor Product Version / Range
Linux Linux e21a9ea81426a85fdb0cdcfcc99d5d9c16b402ab
Linux Linux cc73b2043d106b467accd38e9b1fc09e0607c056
Linux Linux d5d8b8662e6e5a565b47a0388640e88402f23274
Linux Linux 6.18.53
Linux Linux 7.2.7

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
AI Quick Actions have not been generated yet.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-98939. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart