CVE-2026-98520

Yüksək

Təsvir

Linux kernel-də aşağıdakı zəiflik aradan qaldırılmışdır: drm/amdkfd: kfd_dev_mapping funksiyasında use-after-free və çoxkonteynerli boşluq düzəldildi kfd_dev_mapping, birinci /dev/kfd açıcısının address_space məlumatlarını keşləyir ki, GPU sıfırlama yolu doorbell və MMIO diapazonlarının bütün istifadəçi sahəsi mapping-lərini silmək üçün unmap_mapping_range() funksiyasını çağıra bilsin. Bu dizaynın, çox sayda konteyneri olan SRIOV mühitində özünü göstərən iki xətası var: 1. Use-after-free / rwsem deadloqu. Keşlənmiş göstərici birinci açıcının konteynerinə məxsus olan bir inode-a istinad edir. Həmin konteyner bağlandıqda və onun inode-u azad edildikdə, kfd_dev_mapping asılı göstəriciyə (dangling pointer) çevrilir. Sonrakı GPU sıfırlaması zamanı unmap_mapping_range() daxilində bu göstəricidən istifadə olunur və azad edilmiş inode üzərində i_mmap_rwsem götürülür ki, bu da kəsilə bilməyən rwsem gözləməsi kimi müşahidə olunan ciddi donmaya (hard hang) səbəb olur. 2. Çoxkonteynerli boşluq. Yalnız birinci açıcının address_space məlumatları keşlənir; sonrakı açıcılar tərəfindən yaradılan VMA-lar fərqli address_space-də yerləşir və unmap_mapping_range() tərəfindən heç vaxt əhatə edilmir. GPU sıfırlamasından sonra həmin köhnəlmiş mapping-lər doorbell və MMIO səhifələrini qonaq istifadəçi sahəsi üçün əlçatan saxlayır, lakin onların arxasında artıq GPU olmur; bu isə PCIe tranzaksiya taymautlarına və NMI paniklərə risk yaradır. Hər iki xəta DRM nüvəsi (drm_drv.c) tərəfindən istifadə edilən eyni yanaşma ilə düzəldilmişdir: modulun başladılması zamanı şəxsi psevdofaylsistemi yaradılır və ondan bir anonim inode ayrılır. kfd_open() funksiyasında hər bir açıcının file->f_mapping-i həmin inode-un address_space-nə yönləndirilir. Inode modula məxsusdur, tam olaraq amdgpu modulunun ömrü qədər mövcud olur və bütün açıcıların VMA-larını bir address_space-də toplayır. Beləliklə, sıfırlama yolundakı tək bir unmap_mapping_range() çağırışı, asılı göstərici riski olmadan hər bir konteynerin mapping-lərinə düzgün şəkildə çatır. Donma, korlanmış i_mmap_rwsem ilə rwsem_down_read_slowpath()-da ilişib qalmış GPU sıfırlama iş növbəsində (workqueue) NMI backtrace kimi özünü göstərir: 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 (commit 1128b4a52de1572e87431de837fd9850cb99542c-dən cherry pick edildi)

CiddilikYüksək
CVSS7.8
İstismar ehtimalı—
MəhsulLinux
Dərc18 okt 2026
İlk görülmə18 okt 2026

Necə düzəltmək olar

Yeniləyin
  • Linux Linux02b74891624e09a5512c6d84f267d01fcc306a3b, c3a31087b1c8df679b653c1a09d9abe5ff7ec8ef və ya daha yeni versiya

Təsirlənən məhsullar

MəhsulTəsirlənən versiyalarDüzəldildiyi versiya
Linux Linux70cadefcc6160c575b04f763ada34c20e868d577 ≤ v < 02b74891624e09a5512c6d84f267d01fcc306a3b, 70cadefcc6160c575b04f763ada34c20e868d577 ≤ v < c3a31087b1c8df679b653c1a09d9abe5ff7ec8ef, 7.202b74891624e09a5512c6d84f267d01fcc306a3b, c3a31087b1c8df679b653c1a09d9abe5ff7ec8ef

Versiyanızı yoxlayın

Məhsulu seçin və istifadə etdiyiniz versiyanı yazın; versiyanın təsirlənən aralıqda olub-olmadığını görün.

Intelligence 360 paketində

Attack Surface Management

Domenlərinizə bağlı aktivləri, onlarda işləyən texnologiyaları və məlum zəiflikləri bir siyahıda görün.

CVE-2026-98520 · Linux · Dark Radar