KEVWire

Security intelligence, with context.

Response snapshot Oct 27, 2026, 00:37 UTC

Back to the wire
Permalink
VulnerabilityCVE-2026-98520

Linux kernel: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping

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.

At a glance

Exploited
Not known
Severity
7.8 High (CVSS 3.1)
Chance of exploitation
0.2% in the next 30 days
Sources
1 source

What to do

Check the vendor advisory for affected versions and fixes.

Read NVD CVE-2026-98520 (opens a new tab)

What happened

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.

Continue reading

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: <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

(cherry picked from commit 1128b4a52de1572e87431de837fd9850cb99542c)

Scores and how they were measured

CVSS base severity

7.8

Version 3.1As of

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Measurement source (opens a new tab)

How bad it is if exploited. Not a prediction of exploitation or proof you are exposed.

EPSS probability

0.2%

Scored Percentile 5.8%

Model and measurement source (opens a new tab)

A model's estimate of exploitation in the next 30 days, not certainty or your own risk.

Related technology

Sources

  1. Primary source

    NVD CVE-2026-98520 (opens a new tab)

    NVD record: description, CVSS (the CNA score is preferred), affected products, and publication date. Not evidence of exploitation.

    Published Checked

  2. Primary source

    NVD CVE API 2.0 (opens a new tab)

    The NVD API page that supplied this CVE record.

    Published Date not suppliedChecked

  3. Primary source

    FIRST measured EPSS score (opens a new tab)

    Measured EPSS probability and percentile for CVE-2026-98520, scored 2026-10-26. This is a model estimate, not proof of exposure.

    Published Checked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 24). Linux kernel: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping (CVE-2026-98520). https://kevwire.com/record/CVE-2026-98520

MLA

"Linux kernel: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping (CVE-2026-98520)." KEVWire, 24 Oct. 2026, kevwire.com/record/CVE-2026-98520.

Chicago

KEVWire. "Linux kernel: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping (CVE-2026-98520)." Last modified October 24, 2026. https://kevwire.com/record/CVE-2026-98520.

Evidence summary (plain text)

Linux kernel: drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping (Oct 18, 2026).
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:
   <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]
   amdg
CVSS 7.8 (version 3.1; evidence as of Oct 24, 2026; https://nvd.nist.gov/vuln/detail/CVE-2026-98520).
EPSS 0.2% for the following 30 days, scored Oct 26, 2026 (https://api.first.org/data/v1/epss?cve=CVE-2026-98520&date=2026-10-26).
Sources:
NVD CVE-2026-98520: https://nvd.nist.gov/vuln/detail/CVE-2026-98520
NVD CVE API 2.0: https://services.nvd.nist.gov/rest/json/cves/2.0?pubStartDate=2026-10-12T13:35:55.142Z&pubEndDate=2026-10-26T13:35:55.142Z&resultsPerPage=500&startIndex=4500
FIRST measured EPSS score: https://api.first.org/data/v1/epss?cve=CVE-2026-98520&date=2026-10-26
Record ID: CVE-2026-98520.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 26, 2026, 19:40 UTC. Ingestion is not an independent editorial investigation.

NVD status: Received. Publication in the NVD is not evidence of exploitation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are not available yet. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail