{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.2.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "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 --\u003e fs_reclaim --\u003e pool_shrink_rwsem  The cycle is built from three edges:    1) pool_shrink_rwsem -\u003e (init_mm).mmap_lock       The TTM shrinker restores the caching attribute of every page it      frees, while holding pool_shrink_rwsem:         ttm_pool_shrink()        -\u003e ttm_pool_dispose_list()        -\u003e ttm_pool_free_page()        -\u003e set_pages_wb()        -\u003e change_page_attr_set_clr()   [ init_mm mmap read lock ]    2) fs_reclaim -\u003e pool_shrink_rwsem       The same shrinker, called from reclaim.    3) (init_mm).mmap_lock -\u003e fs_reclaim       ioremap() installing a huge PUD mapping over an existing PMD table:         ioremap_page_range()        -\u003e vmap_range_noflush()        -\u003e vmap_try_huge_pud()          [ init_mm mmap read lock ]        -\u003e pud_free_pmd_page()        -\u003e __get_free_page(GFP_KERNEL)  [ enters reclaim ]  [ dhansen: Lots of changelog munging/trimming and merged comments from my \t   version of the fix. ]",
  "id": "DEBIAN-CVE-2026-98939",
  "modified": "2026-10-24T05:47:33.138381372Z",
  "published": "2026-10-23T13:17:14.843Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-98939"
    }
  ],
  "upstream": [
    "CVE-2026-98939"
  ]
}