🔍 CVE-2026-98520

7.8
CVSS Score
HIGH
2026-10-18
2026-10-24 14:16
✅ 완료

🇰🇷 한글 설명

Linux 커널의 AMD GPU 드라이버(amdgpu/amdkfd)에서 kfd_dev_mapping이 첫 번째 /dev/kfd 열기 프로세스의 address_space를 캐싱하면서 발생하는 두 가지 문제를 수정합니다. 첫째, 해당 컨테이너 종료 후 해제된 inode를 참조하는 use-after-free로 GPU 리셋 시 rwsem 교착이 발생하며, 둘째, 이후 열린 컨테이너의 매핑이 unmap되지 않아 리셋 후에도 도어벨/MMIO 페이지가 접근 가능한 상태로 남습니다. 모듈 전용 pseudo-filesystem의 익명 inode를 공유하도록 수정하여 해결합니다.

💡 쉬운 설명

여러 컨테이너가 GPU를 함께 쓰는 환경에서 GPU가 재설정될 때 시스템이 멈추거나 이미 사라진 GPU 메모리 영역에 접근할 수 있는 결함입니다. 커널 수정으로 모든 컨테이너의 메모리 매핑을 하나의 공유 객체로 묶어 재설정 시 빠짐없이 정리되도록 합니다.

🇺🇸 원문 (English)

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] 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)

📍 영향받는 시스템

AMD GPU용 amdgpu/amdkfd 드라이버를 사용하는 SRIOV 다중 컨테이너 환경의 Linux 커널 (수정 커밋 이전 버전)

⚔️ 공격 벡터

로컬 사용자가 여러 컨테이너에서 /dev/kfd를 열고 GPU 리셋을 유발하여 서비스 거부(hang) 또는 잔존 매핑을 통한 비정상 PCIe 접근을 일으킬 수 있음

🛡️ 대응 방법

커널을 해당 커밋(1128b4a52de1572e87431de837fd9850cb99542c)이 포함된 최신 안정 버전으로 업데이트하고 재부팅

🔧 검증 코드

출력된 커널 버전이 패치가 배포된 최신 안정 버전 이상인지 확인하고, amdgpu 모듈이 없으면 이 CVE의 영향을 받지 않으며, 있다면 배포사 보안 공지에서 해당 커널 버전의 패치 포함 여부를 대조합니다.

Shell / Script
uname -r && grep -l amdkfd /proc/modules 2>/dev/null; modinfo amdgpu 2>/dev/null | grep -E '^version|^srcversion'

📊 CVSS Vector String

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

💻 영향받는 소프트웨어

Linux Kernel