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

  - drm/amdkfd：修复kfd_dev_mapping kfd_dev_mapping缓存第一个 /dev/kfd 打开程序的address_space中的释放后使用和多容器间隙，以便 GPU 重置路径可调用 unmap_mapping_range（） 来清除通知和 MMIO 范围的所有用户空间映射。此设计有两个缺陷，在具有多个容器的 SRIOV 下均会显现：1.释放后使用/rwsem 死锁。缓存指针是指第一个打开者的容器所拥有的 inode。当该容器退出并释放其 inode 时，kfd_dev_mapping就会变成一个悬摆指针。后续的 GPU 重置会在 unmap_mapping_range（） 中取消引用其，进而会在释放的 inode 上进行i_mmap_rwsem，进而造成硬挂起，表现为不间断的 rwsem 等待。2、多容器间隙。仅缓存第一个打开者的address_space;更高版本的打开者创建的 VMA 位于不同的 address_space，并且 unmap_mapping_range（） 永远无法访问。
    GPU 重置后，这些过时的映射使来宾用户空间可以访问门铃和 MMIO 页面，而其后面没有 GPU，从而存在 PCIe 事务超时和 NMI 错误的风险。使用与 DRM 核心 （drm_drv.c） 使用的相同方法修复这两个缺陷：在模块初始化时创建私有伪文件系统并从中分配一个匿名 inode。在 kfd_open（） 中，将每个打开者的文件>f_mapping重定向到该 inode 的address_space。该 inode 是模块拥有的，其寿命与 amdgpu 模块的寿命完全相同，并且在一个address_space中收集来自所有打开者的 VMA。然后，重置路径中的单个 unmap_mapping_range（） 调用即可正确到达每个容器的映射，而不存在悬摆指针风险。挂起表现为 GPU 重置工作队列在具有损坏的 i_mmap_rwsem 的情况下卡在 rwsem_down_read_slowpath（） 中旋转时的 NMI 回溯：工作队列：amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu] 调用跟踪： <TASK> kvm_wait+0x1f/0x40 __pv_queued_spin_lock_slowpath+0x31d/0x3a0 _raw_spin_lock_irq+0x51/0x80 rwsem_down_read_slowpath+0xb3/0x550 down_read+0x48/0xd0 unmap_mapping_range+0x71/0x140 kfd_dev_unmap_mapping_range+0x5b/0x140 [amdgpu]amdgpu_amdkfd_clear_kfd_mapping+0xd8/0x190 [amdgpu] amdgpu_device_gpu_recover+0x232/0x450 [amdgpu] xgpu_ai_mailbox_flr_work+0xb5/0xc0 [amdgpu] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 （从提交 1128b4a52de1572e87431de837fd9850cb99542c 中精选出的内容）（CVE-2026-98520）

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

检测

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

medium Nessus 插件 ID 367458

版本 1.1