CVE-2026-98939

Source
https://cve.org/CVERecord?id=CVE-2026-98939
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-98939.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2026-98939
Downstream
Published
2026-10-23T12:12:06Z
Modified
2026-10-25T02:47:29Z
Summary
x86/mm: Drop unnecessary PMD page copy when freeing
Details

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. ]

Database specific
{
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/98xxx/CVE-2026-98939.json"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
e21a9ea81426a85fdb0cdcfcc99d5d9c16b402ab
Fixed
d3c2d2692bdf4af94bb27bc7a3aa0a348a567606
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
cc73b2043d106b467accd38e9b1fc09e0607c056
Fixed
f38c57a28ebbd057471573e39555d5aa11ab03cf
Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
d5d8b8662e6e5a565b47a0388640e88402f23274
Fixed
e3ee38c1bc0b11a8d3e63dce7050759b61864286

Affected versions

v6.*
v6.18.53
v6.18.54
v6.18.55
v7.*
v7.2.7
v7.2.8
v7.2.9

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-98939.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
6.18.53
Fixed
6.18.56
Type
ECOSYSTEM
Events
Introduced
7.2.7
Fixed
7.2.10

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-98939.json"