CVE-2026-98939None▾ SunlitIn 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 …
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Oct 25.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via CVEORG
0.2%
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:
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:
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 ]
fs_reclaim -> pool_shrink_rwsem
The same shrinker, called from reclaim.
(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. ]
Linux >= e21a9ea81426a85fdb0cdcfcc99d5d9c16b402ab < d3c2d2692bdf4af94bb27bc7a3aa0a348a567606Linux >= cc73b2043d106b467accd38e9b1fc09e0607c056 < f38c57a28ebbd057471573e39555d5aa11ab03cfLinux >= d5d8b8662e6e5a565b47a0388640e88402f23274 < e3ee38c1bc0b11a8d3e63dce7050759b61864286Linux >= 6.18.53 < 6.18.56Linux >= 7.2.7 < 7.2.10Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-99118Nonedrm/i915/dmc: Harden DMC firmware payload parsing
CVE-2026-99117Nonenet: bridge: mcast: don't truncate the port group walk on teardown
CVE-2026-99121Noneipv4: avoid divide by zero in fib_rebalance
CVE-2026-99120NoneKVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes
CVE-2026-99119Nonedrm/amdgpu/userq: actually validate userq BOs
CVE-2026-99123Nonevsock/virtio: validate packet source for connected sockets