Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - x86/mm：释放时终止不必要的 PMD 页面复制 在具有独立 GPU 的盒中，一旦 kswapd 缩小 TTM 页面池，lockdep 就会报告可能的死锁。直接原因是将 mmap_read_lock（） 添加到内核页面保护修改代码的 x86 提交。巨大的 vmap 代码对GFP_KERNEL分配保持相同的锁定，现在回收可以获取它是禁忌。该分配位于页表 *free* 路径中，最终用于可疑的用途 [1]。基本上，它会尝试避免在硬件无法访问的页表条目中将硬件设置 Accessed=1，这不是问题。删除 PMD 副本。
    在 PUD 处分离原始 PMD 页面，刷新中间级缓存，并直接从分离的 PMD 页面释放 PTE 表。没有剩余的分配，锁定问题就消失了。Lockdep 崩溃/分析：
    警告：检测到可能的循环锁定依赖关系 7.3.0-rc3-f6e7b42bf05b+ #183 受感染：G U
    ------------------------------------------------------ kswapd0/269 正在尝试获取锁定：
    （（init_mm）.mmap_lock）{++++}-{4:4}， at： change_page_attr_set_clr+0x29a/0x4a0 但任务已经保持锁定： （pool_shrink_rwsem）{.+.+}-{4:4}， at： ttm_pool_shrink+0xb2/0x330 [ttm] 链存在：
    （init_mm）.mmap_lock --> fs_reclaim --> pool_shrink_rwsem 循环由三个边构建：1） pool_shrink_rwsem -> （init_mm）.mmap_lock TTM shrinker 还原其释放的每个页面的缓存属性，同时保持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 同一个 shrinker， 从 reclaim 调用。3） （init_mm）.mmap_lock -> fs_reclaim ioremap（） 在现有 PMD 表上安装大型 PUD 映射：ioremap_page_range（） -> vmap_range_noflush（） -> vmap_try_huge_pud（） [ init_mm mmap 读取锁定 ] -> pud_free_pmd_page（） ->
    __get_free_page（GFP_KERNEL） [ 进入回收 ] [ dhansen： 大量变更日志修改/修剪和来自我的补丁版本的注释。 ]（CVE-2026-98939）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2026-98939

medium Nessus 插件 ID 372342

版本 1.1