---
id: CVE-2026-98939
title: 'x86/mm: Drop unnecessary PMD page copy when freeing'
summary: |-
  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 …
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= e21a9ea81426a85fdb0cdcfcc99d5d9c16b402ab <
    d3c2d2692bdf4af94bb27bc7a3aa0a348a567606
  - >-
    Linux >= cc73b2043d106b467accd38e9b1fc09e0607c056 <
    f38c57a28ebbd057471573e39555d5aa11ab03cf
  - >-
    Linux >= d5d8b8662e6e5a565b47a0388640e88402f23274 <
    e3ee38c1bc0b11a8d3e63dce7050759b61864286
  - Linux >= 6.18.53 < 6.18.56
  - Linux >= 7.2.7 < 7.2.10
published: '2026-10-23'
updated: '2026-10-23'
sourceUpdated: '2026-10-23T12:12:06.180Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-98939'
references:
  - url: 'https://git.kernel.org/stable/c/d3c2d2692bdf4af94bb27bc7a3aa0a348a567606'
  - url: 'https://git.kernel.org/stable/c/f38c57a28ebbd057471573e39555d5aa11ab03cf'
  - url: 'https://git.kernel.org/stable/c/e3ee38c1bc0b11a8d3e63dce7050759b61864286'
tags:
  - cve.org
ingestedAt: '2026-10-23T13:24:55.562Z'
epss: 0.00166
epssPercentile: 0.05842
---

## Overview

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

## Affected

- `Linux >= e21a9ea81426a85fdb0cdcfcc99d5d9c16b402ab < d3c2d2692bdf4af94bb27bc7a3aa0a348a567606`
- `Linux >= cc73b2043d106b467accd38e9b1fc09e0607c056 < f38c57a28ebbd057471573e39555d5aa11ab03cf`
- `Linux >= d5d8b8662e6e5a565b47a0388640e88402f23274 < e3ee38c1bc0b11a8d3e63dce7050759b61864286`
- `Linux >= 6.18.53 < 6.18.56`
- `Linux >= 7.2.7 < 7.2.10`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.