{"id":"CVE-2026-98939","kind":"vulnerability","aliases":["CVE-2026-98939"],"related":[],"title":"Linux kernel x86 huge-vmap path can deadlock during memory reclaim","description":"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 --> fs_reclaim --> pool_shrink_rwsem\n\nThe cycle is built from three edges:\n\n  1) pool_shrink_rwsem -> (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       -> ttm_pool_dispose_list()\n       -> ttm_pool_free_page()\n       -> set_pages_wb()\n       -> change_page_attr_set_clr()   [ init_mm mmap read lock ]\n\n  2) fs_reclaim -> pool_shrink_rwsem\n\n     The same shrinker, called from reclaim.\n\n  3) (init_mm).mmap_lock -> fs_reclaim\n\n     ioremap() installing a huge PUD mapping over an existing PMD table:\n\n       ioremap_page_range()\n       -> vmap_range_noflush()\n       -> vmap_try_huge_pud()          [ init_mm mmap read lock ]\n       -> pud_free_pmd_page()\n       -> __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. ]","summary":"On x86, the huge vmap code allocated memory with GFP_KERNEL while holding the init_mm mmap lock, which can deadlock when kswapd reclaims memory, as lockdep showed with a discrete GPU's TTM pool shrinker. The fix removes that allocation by freeing PTE tables straight from the detached PMD page.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["linux-kernel","runtime","self-hosted","x86"],"not_affected_if":["non-x86-architecture"],"how_to_check":"- Run `uname -r` and compare against the fixed kernel builds listed in the NVD entry for CVE-2026-98939\n- unknown","fix":"- Update the Linux kernel to a build that includes the upstream commit for CVE-2026-98939 (check the NVD or distro advisory for the exact version)\n- unknown","status":"open","published_at":"2026-10-23T13:17:14+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","triaged_at":"2026-10-25T04:58:03+00:00","updated_at":"2026-10-25T04:58:03+00:00","category":"runtime","confidence":0.5,"triage":{"at":"2026-10-25T04:58:03Z","model":"claude-haiku-5-5","output":{"fix":"- Update the Linux kernel to a build that includes the upstream commit for CVE-2026-98939 (check the NVD or distro advisory for the exact version)\n- unknown","reach":"local","title":"Linux kernel x86 huge-vmap path can deadlock during memory reclaim","impact":"low","summary":"On x86, the huge vmap code allocated memory with GFP_KERNEL while holding the init_mm mmap lock, which can deadlock when kswapd reclaims memory, as lockdep showed with a discrete GPU's TTM pool shrinker. The fix removes that allocation by freeing PTE tables straight from the detached PMD page.","category":"runtime","nicknames":[],"who_cares":["linux-kernel","x86","self-hosted"],"confidence":0.5,"needs_auth":"no","worst_case":"kernel deadlock under memory pressure, causing system hang","analyst_note":"Sources give no affected version range, fixed version or exploitability; check the NVD entry and the upstream kernel commit for affected and fixed versions.","how_to_check":"- Run `uname -r` and compare against the fixed kernel builds listed in the NVD entry for CVE-2026-98939\n- unknown","needs_analyst":true,"not_affected_if":["non-x86-architecture"],"who_is_affected":"Systems running an affected Linux kernel on x86, most likely hosts with a discrete GPU using the TTM page pool under memory pressure, where reclaim can trigger the lock cycle. The sources do not give a version range, so unknown.","user_interaction":"no","needs_special_setup":"unknown","severity_if_unknown":"low"},"cost_usd":0.000706,"input_tokens":4207,"output_tokens":570,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'+0':273C,290C '-2026':14A,17A '-98939':15A,18A '1':177C,186C,312C '183':251C '2':361C '3':373C '4':265C,266C,284C,285C '7.3.0':247C 'access':185C 'acquir':259C 'add':125C 'alloc':33B,67B,148C,162C,232C 'alreadi':278C 'attr':270C,353C 'attribut':326C 'avoid':182C 'basic':178C 'box':98C 'built':308C 'cach':218C,325C 'call':370C 'caus':119C 'chain':293C 'chang':268C,351C 'changelog':420C 'circular':243C 'clr':272C,355C 'code':32B,135C,139C 'comment':424C 'commit':123C 'copi':93C,204C 'cve':13A,16A 'cycl':306C 'deadlock':9A,47B,107C 'depend':245C 'detach':75B,205C,227C 'detect':246C 'dhansen':417C 'discret':57B,101C 'dispos':342C 'drop':89C 'dubious':175C 'edg':311C 'end':171C 'enter':415C 'entri':190C 'everi':328C 'exist':294C,388C 'f6e7b42bf05b':250C 'fix':64B,430C 'flush':213C 'follow':83C 'free':69B,95C,168C,220C,331C,346C,407C,411C 'fs':300C,362C,378C 'g':253C 'get':410C 'gfp':36B,146C,413C 'gone':238C 'gpu':58B,102C 'hardwar':183C,196C 'hold':39B,140C,279C,333C 'host':25B 'huge':5A,30B,137C,383C,399C 'huge-vmap':4A 'immedi':118C 'init':41B,261C,296C,316C,356C,374C,401C 'instal':381C 'ioremap':380C,391C 'issu':200C,236C 'kernel':2A,21B,37B,81C,131C,147C,414C 'kswapd':49B,111C 'kswapd0/269':255C 'left':233C 'level':217C 'linux':1A,20B,80C 'linux-kernel':19B 'list':343C 'lock':44B,129C,143C,235C,244C,260C,264C,280C,299C,319C,360C,377C,405C 'lockdep':53B,103C,239C 'lot':418C 'map':385C 'memori':11A,34B,51B 'merg':423C 'mid':216C 'mid-level':215C 'mm':42B,262C,297C,317C,357C,375C,402C 'mmap':43B,127C,263C,298C,318C,358C,376C,403C 'mung':134C 'munging/trimming':421C 'no-no':152C 'noflush':396C 'non':199C 'non-issu':198C 'origin':207C 'page':77B,92C,115C,132C,166C,188C,209C,229C,269C,329C,347C,349C,352C,392C,409C,412C 'path':7A,169C 'pmd':76B,91C,203C,208C,228C,389C,408C 'pool':61B,116C,281C,288C,302C,313C,334C,338C,341C,345C,364C 'possibl':106C,242C 'protect':133C 'pte':70B,222C 'pud':212C,384C,400C,406C 'purpos':176C 'rang':393C,395C 'rc3':249C 'rc3-f6e7b42bf05b':248C 'read':128C,359C,404C 'reclaim':12A,50B,157C,301C,363C,372C,379C,416C 'remov':65B,201C 'report':104C 'resolv':87C 'restor':323C 'runtim':22B 'rwsem':283C,304C,315C,336C,366C 'self':24B 'self-host':23B 'set':184C,271C,348C,354C 'show':54B 'shrink':112C,282C,289C,303C,314C,335C,339C,365C 'shrinker':62B,322C,369C 'soon':109C 'splat/analysis':240C 'straight':72B,224C 'tabl':71B,167C,189C,223C,390C 'taint':252C 'take':159C 'task':276C 'three':310C 'tri':180C,257C,398C 'ttm':60B,114C,287C,292C,321C,337C,340C,344C 'u':254C 'unnecessari':90C 'unreach':193C 'version':427C 'vmap':6A,31B,138C,394C,397C 'vulner':84C 'warn':241C 'wb':350C 'x29a/0x4a0':274C 'x86':3A,26B,28B,122C 'x86/mm':88C 'xb2/0x330':291C","nicknames":[],"mitigations":[],"who_affected":"Systems running an affected Linux kernel on x86, most likely hosts with a discrete GPU using the TTM page pool under memory pressure, where reclaim can trigger the lock cycle. The sources do not give a version range, so unknown.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-23T13:17:14+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-98939","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-98939","severity":null,"published_at":"2026-10-23T13:17:14+00:00","modified_at":"2026-10-23T13:17:14+00:00","first_seen_at":"2026-10-23T21:57:33+00:00","fetched_at":"2026-10-23T22:29:03+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}