FKIE_CVE-2026-98939
Vulnerability from fkie_nvd - Published: 2026-10-23 13:17 - Updated: 2026-10-23 13:17
Severity
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 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. ]
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/x86/mm/pgtable.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "d3c2d2692bdf4af94bb27bc7a3aa0a348a567606",
"status": "affected",
"version": "e21a9ea81426a85fdb0cdcfcc99d5d9c16b402ab",
"versionType": "git"
},
{
"lessThan": "f38c57a28ebbd057471573e39555d5aa11ab03cf",
"status": "affected",
"version": "cc73b2043d106b467accd38e9b1fc09e0607c056",
"versionType": "git"
},
{
"lessThan": "e3ee38c1bc0b11a8d3e63dce7050759b61864286",
"status": "affected",
"version": "d5d8b8662e6e5a565b47a0388640e88402f23274",
"versionType": "git"
}
]
},
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/x86/mm/pgtable.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "6.18.56",
"status": "affected",
"version": "6.18.53",
"versionType": "semver"
},
{
"lessThan": "7.2.10",
"status": "affected",
"version": "7.2.7",
"versionType": "semver"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Drop unnecessary PMD page copy when freeing\n\nOn a box with a discrete GPU, lockdep reports a possible deadlock as\nsoon as kswapd shrinks the TTM page pool. The immediate cause is an\nx86 commit that added an mmap_read_lock() to kernel page protection\nmunging code.\n\nThe huge vmap code holds the same lock over a GFP_KERNEL allocation,\nwhich is a no-no now that reclaim can take it. That allocation is in a\npage table *free* path and ends up being for dubious purposes[1].\nBasically, it tries to avoid hardware setting Accessed=1 in page table\nentries that are unreachable by the hardware, a non-issue.\n\nRemove the PMD copy. Detach the original PMD page at the PUD, flush\nthe mid-level caches, and free the PTE tables straight from the\ndetached PMD page. With no allocation left, the locking issue is gone.\n\nLockdep splat/analysis:\n\n WARNING: possible circular locking dependency detected\n 7.3.0-rc3-f6e7b42bf05b+ #183 Tainted: G U\n ------------------------------------------------------\n kswapd0/269 is trying to acquire lock:\n ((init_mm).mmap_lock){++++}-{4:4}, at: change_page_attr_set_clr+0x29a/0x4a0\n but task is already holding lock:\n (pool_shrink_rwsem){.+.+}-{4:4}, at: ttm_pool_shrink+0xb2/0x330 [ttm]\n Chain exists of:\n (init_mm).mmap_lock --\u003e fs_reclaim --\u003e pool_shrink_rwsem\n\nThe cycle is built from three edges:\n\n 1) pool_shrink_rwsem -\u003e (init_mm).mmap_lock\n\n The TTM shrinker restores the caching attribute of every page it\n frees, while holding pool_shrink_rwsem:\n\n ttm_pool_shrink()\n -\u003e ttm_pool_dispose_list()\n -\u003e ttm_pool_free_page()\n -\u003e set_pages_wb()\n -\u003e change_page_attr_set_clr() [ init_mm mmap read lock ]\n\n 2) fs_reclaim -\u003e pool_shrink_rwsem\n\n The same shrinker, called from reclaim.\n\n 3) (init_mm).mmap_lock -\u003e fs_reclaim\n\n ioremap() installing a huge PUD mapping over an existing PMD table:\n\n ioremap_page_range()\n -\u003e vmap_range_noflush()\n -\u003e vmap_try_huge_pud() [ init_mm mmap read lock ]\n -\u003e pud_free_pmd_page()\n -\u003e __get_free_page(GFP_KERNEL) [ enters reclaim ]\n\n[ dhansen: Lots of changelog munging/trimming and merged comments from my\n\t version of the fix. ]"
}
],
"id": "CVE-2026-98939",
"lastModified": "2026-10-23T13:17:14.843",
"metrics": {},
"published": "2026-10-23T13:17:14.843",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d3c2d2692bdf4af94bb27bc7a3aa0a348a567606"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e3ee38c1bc0b11a8d3e63dce7050759b61864286"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f38c57a28ebbd057471573e39555d5aa11ab03cf"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.