Description
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. ]
Published: 2026-10-23
Score: n/a
EPSS: n/a
KEV: No
Impact: Potential deadlock leading to memory reclamation stalls and possible service interruption
Action: Apply Patch
AI Analysis

Impact

The reported issue occurs in the Linux kernel’s memory management for x86 architectures, where an unnecessary copy of a page middle directory (PMD) page during free operations caused a circular locking dependency. The deadlock cycle involves the mmap_lock taken when changing page attributes, the pool_shrink_rwsem used during TTM page pool shrinkage, and a re-entrant acquisition of mmap_lock during ioremap. As a result, kswapd can become blocked, leading to stalled memory reclamation and system performance degradation. This does not provide direct data disclosure or arbitrary code execution, but the denial‑of‑service impact could be critical on production systems with discrete GPUs.

Affected Systems

The vulnerability affects all Linux kernel versions that compile with the x86 memory management code described, specifically those including the TTM page pool handling and ioremap functions. The exact version range is not listed, but the patch is present in newer kernel releases such as 7.3.0-rc3 and later, and any kernel that has incorporated the commit added to prevent PMD copy during freeing.

Risk and Exploitability

The impact is a lock ordering bug that can lead to deadlock under normal kernel operation when the system performs memory reclamation. The CVSS score is not provided, and the EPSS score is unavailable, suggesting that the exploitability data is not currently published. The vulnerability is not listed in CISA’s KEV catalog. Inferred attack vector is internal, requiring normal kernel execution paths; an attacker on a compromised system can trigger the deadlock by inducing memory pressure, but no remote exploitation path is described.

Generated by OpenCVE AI on October 23, 2026 at 14:30 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the patch removing the unnecessary PMD copy during freeing (e.g., 7.3.0-rc3 or later).
  • Ensure any GPU drivers or kernel modules that interact with the TTM pool are also updated to the latest released versions to avoid re‑introducing the deadlock path.
  • After updating, monitor system logs and lockdep for any residual deadlock warnings, and adjust memory reclamation settings if necessary to mitigate potential stalls.

Generated by OpenCVE AI on October 23, 2026 at 14:30 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 23 Oct 2026 17:15:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Fri, 23 Oct 2026 15:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Fri, 23 Oct 2026 12:30:00 +0000

Type Values Removed Values Added
Description 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. ]
Title x86/mm: Drop unnecessary PMD page copy when freeing
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-23T12:12:06.180Z

Reserved: 2026-09-25T10:25:14.381Z

Link: CVE-2026-98939

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-23T13:17:14.843

Modified: 2026-10-23T13:17:14.843

Link: CVE-2026-98939

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-23T17:00:14Z

Weaknesses