Linux kernel x86 huge vmap allocation can deadlock during reclaim
Key facts
- Attack vector
- —
- Privileges required
- —
- User interaction
- —
- Attack complexity
- —
- Impact type
- —
- Confidentiality · integrity · availability
- —
- Fix status
- Partial Red Hat: 7 without a fix
No CVSS vector from any source. Fix status from CNA and Red Hat.
Summary
Linux kernel versions from 6.18.53 before 6.18.56 and from 7.2.7 before 7.2.10 are affected. The x86 huge vmap code makes a GFP_KERNEL allocation while holding the mmap lock during a page table free, which can deadlock with memory reclaim. Lockdep reports the cycle when kswapd shrinks the TTM page pool on a system with a discrete GPU.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
Description from the CNA
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. ]
Why it matters now
SSVC decision points
Not available: CISA has not published SSVC decision points for this record.
Affected products
Remediation
Fixed versions are Linux kernel 6.18.56 and 7.2.10. Red Hat Enterprise Linux 6, 7, 8, 9 and 10 and Red Hat OpenShift Container Platform 4 and 5 are affected without a fix. Red Hat lists no fix planned for Red Hat Enterprise Linux 6, and no fix available for the other listed products.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
- Fix · CNA Linux (Linux) Fixed in 6.18.56, 7.2.10
Vendor assessments
Red Hat
Red Hat rating: Moderate. Red Hat's page for this CVE →
| Product | Status | Plan or fix |
|---|---|---|
| Red Hat Enterprise Linux 10 | Affected | No fix yet: Fix deferred |
| Red Hat Enterprise Linux 6 | Affected | No fix planned: Out of support scope |
| Red Hat Enterprise Linux 7 | Affected | No fix yet: Fix deferred |
| Red Hat Enterprise Linux 8 | Affected | No fix yet: Fix deferred |
| Red Hat Enterprise Linux 9 | Affected | No fix yet: Fix deferred |
| Red Hat OpenShift Container Platform 4 | Affected | No fix yet: Fix deferred |
| Red Hat OpenShift Container Platform 5 | Affected | No fix yet: Fix deferred |
Timeline
- 2026-10-23 Threatist record created from CVE-2026-98939
- 2026-10-23 Alias added: GHSA-6vp7-hj7x-73jj
- 2026-10-30 Affected versions changed · Red Hat
- 2026-10-30 CVSS score added · Red Hat
- 2026-11-06 Affected versions changed · Red Hat
References
More Linux vulnerabilities
- TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
- TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
- TI-2021-02452 Incorrect authorization in Ubuntu linux kernel KEVCVSS 3.1HIGH 8.8
- TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
- TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
- TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
Sources
- CVE-2026-98939 · CVE Program
- CVE-2026-98939 · NVD
- FIRST EPSS
- GHSA-6vp7-hj7x-73jj · GitHub Advisory Database · CC BY 4.0
- CVE-2026-98939 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences