UBUNTU-CVE-2026-98939: Medium severity ubuntu/linux-hwe-edge vulnerability
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 mmapreadlock() to kernel page protection munging code. The huge vmap code holds the same lock over a GFPKERNEL 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: ((initmm).mmaplock){++++}-{4:4}, at: changepageattrsetclr+0x29a/0x4a0 but task is already holding lock: (poolshrinkrwsem){.+.+}-{4:4}, at: ttmpoolshrink+0xb2/0x330 [ttm] Chain exists of: (initmm).mmaplock --> fsreclaim --> poolshrinkrwsem The cycle is built from three edges: 1) poolshrinkrwsem -> (initmm).mmaplock The TTM shrinker restores the caching attribute of every page it frees, while holding poolshrinkrwsem: ttmpoolshrink() -> ttmpooldisposelist() -> ttmpoolfreepage() -> setpageswb() -> changepageattrsetclr() [ initmm mmap read lock ] 2) fsreclaim -> poolshrinkrwsem The same shrinker, called from reclaim. 3) (initmm).mmaplock -> fsreclaim ioremap() installing a huge PUD mapping over an existing PMD table: ioremappagerange() -> vmaprangenoflush() -> vmaptryhugepud() [ initmm mmap read lock ] -> pudfreepmdpage() -> getfreepage(GFPKERNEL) [ enters reclaim ] [ dhansen: Lots of changelog munging/trimming and merged comments from my version of the fix. ]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Remove the unnecessary PMD page copy from the x86/mm page-table freeing path, eliminating the GFP_KERNEL allocation in the huge vmap code while holding the mmap lock.