CVE-2026-98520 in Linux
요약
\~에 의해 VulDB • 2026. 10. 19.
리눅스 커널에서 다음 취약점이 해결되었습니다:
drm/amdkfd: kfd_dev_mapping의 use-after-free 및 다중 컨테이너 간격 문제 수정
kfd_dev_mapping은 첫 번째 /dev/kfd 오프너의 address_space를 캐싱하여, GPU 리셋 경로가 doorbell 및 MMIO 범위의 모든 사용자 공간 매핑을 지우기 위해 unmap_mapping_range()를 호출할 수 있도록 합니다. 이 설계에는 SRIOV 환경에서 여러 컨테이너가 있을 때 나타나는 두 가지 버그가 있습니다:
1. Use-after-free / rwsem 데드락. 캐시된 포인터는 첫 번째 오프너의 컨테이너에 속하는 inode를 참조합니다. 해당 컨테이너가 종료되고 그 inode가 해제되면 kfd_dev_mapping은 덩글링 포인터(dangling pointer)가 됩니다. 이후 GPU 리셋 시 unmap_mapping_range() 내부에서 이 freed된 inode의 i_mmap_rwsem을 획득하려고 시도하며, 이는 uninterruptible rwsem 대기 상태로 관찰 가능한 하드 해нг(hang)을 유발합니다.
2. 다중 컨테이너 간격(Multi-container gap). 첫 번째 오프너의 address_space만 캐싱되므로, 이후에 열린 오프너들이 생성한 VMAs는 서로 다른 address_space에 위치하며 unmap_mapping_range()로 접근되지 않습니다. GPU 리셋 후 이러한 오래된 매핑들은 뒤따르는 GPU 없이도 게스트 사용자 공간에서 doorbell 및 MMIO 페이지를 계속 접근 가능하게 만들어 PCIe 트랜잭션 타임아웃과 NMI 패닉의 위험을 초래합니다.
DRM 코어(drm_drv.c)와 동일한 방식으로 두 버그 모두 수정합니다: 모듈 초기화 시점에 프라이빗 pseudo-파일시스템을 생성하고, 여기서 하나의 익명 inode를 할당합니다. kfd_open()에서 모든 오프너의 file->f_mapping을 해당 inode의 address_space로 리디렉션합니다. 이 inode는 모듈 소유이며 amdgpu 모듈이 존재하는 동안만 생존하며, 모든 오프너들의 VMAs를 단일 address_space에 수집합니다. 리셋 경로에서의 단 한 번의 unmap_mapping_range() 호출은 덩글링 포인터 위험 없이 각 컨테이너의 매핑을 올바르게 도달하게 합니다.
해نگ(hang)은 GPU 리셋 작업 큐에서 rwsem_down_read_slowpath() 내에서 스피닝하며 멈춰 있는 NMI 백트레이스 형태로 나타납니다:
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
(커밋 1128b4a52de1572e87431de837fd9850cb99542c에서 cherry picked됨)
VulDB is the best source for vulnerability data and more expert information about this specific topic.