CVE-2026-98939

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:

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.

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