Vulnerability · CVE-2026-98520

CVE-2026-98520: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping

Published Oct 18, 2026 · catalog updated Oct 18, 2026 · Linux Linux

Open the advisory

Exploitation likelihood is not on this record for CVE-2026-98520. A missing EPSS score is not a low risk. Compare Linux Linux with the linked advisory before you change production.

Gaps on this record

No version range is stored. A customer cannot check an installed version against this record.
No vendor fix or required action is stored. Compare the linked advisory before you change production.
EPSS is missing. A missing score is not a low risk.

Severity: Unknown—
Known exploitation: Not in CISA/VulnCheck KEV
EPSS: Awaiting synchronization with FIRST
Remediation: Not established
Affected products: linux kernel · vendor Linux Linux

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping kfd_dev_mapping caches the address_space of the first /dev/kfd opener so that the GPU reset path can call unmap_mapping_range() to zap all userspace mappings of doorbell and MMIO ranges. This design has two bugs that both manifest under SRIOV with multiple containers: 1. Use-after-free / rwsem deadlock. The cached pointer refers to an inode owned by the first opener's container. When that container exits and its inode is released, kfd_dev_mapping becomes a dangling pointer. A subsequent GPU reset dereferences it inside unmap_mapping_range(), which takes i_mmap_rwsem on the freed inode, causing a hard hang observable as an uninterruptible rwsem wait. 2. Multi-container gap. Only the first opener's address_space is cached; VMAs created by later openers live in a different address_space and are never reached by unmap_mapping_range(). After a GPU reset those stale mappings keep doorbell and MMIO pages accessible to guest userspace with no GPU behind them, risking PCIe transaction timeouts and NMI panics. Fix both bugs with the same approach used by DRM core (drm_drv.c): create a private pseudo-filesystem at module init time and allocate one anonymous inode from it. In kfd_open() redirect every opener's file->f_mapping to that inode's address_space. The inode is module-owned, lives exactly as long as the amdgpu module, and collects VMAs from all openers in one address_space. A single unmap_mapping_range() call in the reset path then correctly reaches every container's mappings with no dangling pointer risk. The hang manifests as an NMI backtrace on the GPU reset workqueue stuck spinning in rwsem_down_read_slowpath() with a corrupted i_mmap_rwsem: Workqueue: amdgpu-reset-dev xgpu_ai_mailbox_flr_work [amdgpu] Call Trace: kvm_wait+0x1f/0x40 __pv_queued_spin_lock_slowpath+0x31d/0x3a0 _raw_spin_lock_irq+0x51/0x80 rwsem_down_read_slowpat

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

linux kernelversion unspecified
vendor Linux Linuxversion unspecified

How to fix CVE-2026-98520

Recommended remediation
No required-action text, fix commit, or clear fixed-version range is stored yet.
Official advisories

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

Exploitation likelihood is not on this record for CVE-2026-98520. A missing EPSS score is not a low risk. Compare Linux Linux with the linked advisory before you change production.

Which versions are affected?

Affected version ranges are not on this record. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

No weakness class is stored. EPSS is not on this record yet. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

Oct 18, 2026 · Linux Kernel CVE
Detected
From: Greg Kroah-Hartman Description =========== In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping kfd_dev_mapping caches the address_space of the first /dev/kfd opener so that the GPU reset path can call unmap_mapping_range() to zap all userspace mappings of doorbell and MMIO ranges. This design has two bu
Oct 18, 2026 · NIST NVD
Updated
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping kfd_dev_mapping caches the address_space of the first /dev/kfd opener so that the GPU reset path can call unmap_mapping_range() to zap all userspace mappings of doorbell and MMIO ranges. This design has two bugs that both manifest under SRIOV with multiple c

Sources

CVE.orgVulnerability recordCVE-2026-98520
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping kfd_dev_mapping caches the address_space of the first /dev/kfd opener so that the GPU reset path can call unmap_mapping_range() to zap all
cve.org
Linux Kernel CVEVendor advisoryCVE-2026-98520
From: Greg Kroah-Hartman Description =========== In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping kfd_dev_mapping caches the address_space of the first /dev/kfd opener so that the GPU res
git.kernel.org
NIST NVDVulnerability recordCVE-2026-98520
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping kfd_dev_mapping caches the address_space of the first /dev/kfd opener so that the GPU reset path can call unmap_mapping_range() to zap a
nvd.nist.gov

References

Freshness

Last verified in this catalog Oct 18, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.