In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
drm\/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping<\/p>\n
kfd_dev_mapping caches the address_space of the first \/dev\/kfd opener
\nso that the GPU reset path can call unmap_mapping_range() to zap all
\nuserspace mappings of doorbell and MMIO ranges. This design has two
\nbugs that both manifest under SRIOV with multiple containers:<\/p>\n
1. Use-after-free \/ rwsem deadlock. The cached pointer refers to an
\n inode owned by the first opener’s container. When that container
\n exits and its inode is released, kfd_dev_mapping becomes a dangling
\n pointer. A subsequent GPU reset dereferences it inside
\n unmap_mapping_range(), which takes i_mmap_rwsem on the freed inode,
\n causing a hard hang observable as an uninterruptible rwsem wait.<\/p>\n
2. Multi-container gap. Only the first opener’s address_space is cached;
\n VMAs created by later openers live in a different address_space and
\n are never reached by unmap_mapping_range(). After a GPU reset those
\n stale mappings keep doorbell and MMIO pages accessible to guest
\n userspace with no GPU behind them, risking PCIe transaction timeouts
\n and NMI panics.<\/p>\n
Fix both bugs with the same approach used by DRM core (drm_drv.c):
\ncreate a private pseudo-filesystem at module init time and allocate one
\nanonymous inode from it. In kfd_open() redirect every opener’s
\nfile->f_mapping to that inode’s address_space. The inode is
\nmodule-owned, lives exactly as long as the amdgpu module, and collects
\nVMAs from all openers in one address_space. A single
\nunmap_mapping_range() call in the reset path then correctly reaches
\nevery container’s mappings with no dangling pointer risk.<\/p>\n
The hang manifests as an NMI backtrace on the GPU reset workqueue stuck
\nspinning in rwsem_down_read_slowpath() with a corrupted i_mmap_rwsem:<\/p>\n
Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu]
\n Call Trace:<\/p>\n
kvm_wait+0x1f\/0x40
\n __pv_queued_spin_lock_slowpath+0x31d\/0x3a0
\n _raw_spin_lock_irq+0x51\/0x80
\n rwsem_down_read_slowpath+0xb3\/0x550
\n down_read+0x48\/0xd0
\n unmap_mapping_range+0x71\/0x140
\n kfd_dev_unmap_mapping_range+0x5b\/0x140 [amdgpu]
\n amdgpu_amdkfd_clear_kfd_mapping+0xd8\/0x190 [amdgpu]
\n amdgpu_device_gpu_recover+0x232\/0x450 [amdgpu]
\n xgpu_ai_mailbox_flr_work+0xb5\/0xc0 [amdgpu]
\n process_one_work+0x18e\/0x3e0
\n worker_thread+0x2e3\/0x420
\n kthread+0x10a\/0x230<\/p>\n
(cherry picked from commit 1128b4a52de1572e87431de837fd9850cb99542c)<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
drm\/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping<\/p>\n
kfd_dev_mapping caches the address_space of the first \/d<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-40992","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/40992","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=40992"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=40992"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=40992"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}