{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2026-98520", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2026-09-25T10:25:14.354Z", "datePublished": "2026-10-18T15:17:38.113Z", "dateUpdated": "2026-10-24T14:09:16.913Z" }, "containers": { "cna": { "providerMetadata": { "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2026-10-24T14:09:16.913Z" }, "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping\n\nkfd_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:\n\n1. 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.\n\n2. 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.\n\nFix 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.\n\nThe hang manifests as an NMI backtrace on the GPU reset workqueue stuck\nspinning in rwsem_down_read_slowpath() with a corrupted i_mmap_rwsem:\n\n Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu]\n Call Trace:\n \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\n\n(cherry picked from commit 1128b4a52de1572e87431de837fd9850cb99542c)" } ], "metrics": [ { "cvssV3_1": { "version": "3.1", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "baseScore": 7.8, "baseSeverity": "HIGH" }, "scenarios": [ { "lang": "en", "value": "AV:L - openat(2) on /dev/kfd reaches chrdev_open()->kfd_open(), which caches inode->i_mapping; local KFD queue operations can later drive kfd_hws_hang()->amdgpu_device_gpu_recover()->amdgpu_amdkfd_clear_kfd_mapping()->kfd_dev_unmap_mapping_range(). No remote protocol supplies this state.\nAC:L - In the affected SR-IOV multi-container setup, one tenant can exit its first GPU container to free the cached inode, then use a non-preemptible queue from another container; its unmap_queues_cpsch() timeout calls kfd_hws_hang() and schedules the reset without an uncontrolled race.\nPR:L - kfd_open() has no capability check, and AMDKFD_IOC_CREATE_QUEUE and AMDKFD_IOC_DESTROY_QUEUE have ioctl flags 0. The attacker needs only ordinary access to /dev/kfd as granted to a render-group user or GPU container, not init-namespace administration.\nUI:N - The attacker opens /dev/kfd, creates the relevant mappings and queues, exits containers, and induces queue teardown/reset through their own operations. No separate victim must open a file, mount media, or initiate the reset.\nS:U - The freed address_space, corrupted i_mmap_rwsem, and resulting hang or memory corruption are inside the same guest kernel running amdkfd. The code does not bypass the SR-IOV/IOMMU boundary or affect the physical host kernel.\nC:H - kfd_dev_mapping points to the first container inode's embedded i_data after that inode is RCU-freed; unmap_mapping_range() then reads reclaimed i_mmap and VMA pointers. Heap reclamation of this inode/mapping UAF can provide kernel-memory disclosure.\nI:H - unmap_mapping_range() takes and releases the freed mapping's i_mmap_rwsem and may traverse and zap through reclaimed i_mmap nodes, modifying freed inode slab and page-table state. Heap grooming can convert these UAF writes into arbitrary corruption or control-flow hijacking.\nA:H - The observed reset path hangs in rwsem_down_read_slowpath on the freed i_mmap_rwsem. Independently, later-container VMAs omitted from that mapping retain doorbell/MMIO access after reset, allowing PCIe transaction timeouts and NMI panics." } ] } ], "affected": [ { "product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "drivers/gpu/drm/amd/amdkfd/kfd_chardev.c" ], "versions": [ { "version": "70cadefcc6160c575b04f763ada34c20e868d577", "lessThan": "02b74891624e09a5512c6d84f267d01fcc306a3b", "status": "affected", "versionType": "git" }, { "version": "70cadefcc6160c575b04f763ada34c20e868d577", "lessThan": "c3a31087b1c8df679b653c1a09d9abe5ff7ec8ef", "status": "affected", "versionType": "git" } ] }, { "product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": [ "drivers/gpu/drm/amd/amdkfd/kfd_chardev.c" ], "versions": [ { "version": "7.2", "status": "affected" }, { "version": "0", "lessThan": "7.2", "status": "unaffected", "versionType": "semver" }, { "version": "7.2.9", "lessThanOrEqual": "7.2.*", "status": "unaffected", "versionType": "semver" }, { "version": "7.3", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix" } ] } ], "cpeApplicability": [ { "nodes": [ { "operator": "OR", "negate": false, "cpeMatch": [ { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "7.2", "versionEndExcluding": "7.2.9" }, { "vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "7.2", "versionEndExcluding": "7.3" } ] } ] } ], "references": [ { "url": "https://git.kernel.org/stable/c/02b74891624e09a5512c6d84f267d01fcc306a3b" }, { "url": "https://git.kernel.org/stable/c/c3a31087b1c8df679b653c1a09d9abe5ff7ec8ef" } ], "title": "drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping", "x_generator": { "engine": "bippy-1.2.0" } } } }