CVE-2026-98473

Aşağı

Təsvir

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: s390/vfio-ap: növbə host konfiqurasiyasından silindikdə KVM GISC və səhifə sızmasının düzəldilməsi Bir növbə mediasiya edilmiş cihazla (mdev) təyin edildiyi halda hostun AP konfiqurasiyasından silindikdə, KVM interrupt və səhifə resurslarının idarə edilməsində üç əlaqəli problem mövcuddur. Problem 1: ~~~~~~~~~ vfio_ap_mdev_reset_queue() funksiyasında AP_RESPONSE_Q_NOT_AVAIL idarə olunmur AP şinası, adapteri və ya domeni hostun AP konfiqurasiyasından silinmiş növbə cihazını sildikdə, vfio_ap_mdev_remove_queue() çağırılır. Əgər həmin anda növbə hələ də hostun AP konfiqurasiyasında qalmışsa, o, PQAP(ZAPQ) göndərən vfio_ap_mdev_reset_queue() funksiyasını çağırır. Adapter artıq host konfiqurasiyasından çıxdığı üçün ap_zapq() AP_RESPONSE_Q_NOT_AVAIL (0x01) qaytarır. Bu cavab kodu vfio_ap_mdev_reset_queue() funksiyasının switch operatorunda idarə olunmur və default halına keçir ki, bu da WARN verir lakin vfio_ap_free_aqic_resources() funksiyasını çağırmır. Nəticədə, əgər qonaq tərəfindən növbə üçün IRQ idarəetməsi aktiv edilibsə, KVM GISC qeydiyyatı və bildiriş indikator baytını (NIB) saxlayan sabitləndirilmiş qonaq səhifəsi sızır. Bu, vfio_ap_mdev_reset_queue() funksiyasında AP_RESPONSE_Q_NOT_AVAIL kodunun AP_RESPONSE_DECONFIGURED və AP_RESPONSE_CHECKSTOPPED ilə eyni hala əlavə edilməsi ilə düzəldilir. Digər cavab kodları kimi, Q_NOT_AVAIL növbənin işlək olmadığını və daha çox sıfırlama cəhdinin mümkün olmadığını göstərir; düzgün hərəkət IRQ resurslarını dərhal azad etməkdir. Problem 2: ~~~~~~~~~ apq_status_check() funksiyasında AP_RESPONSE_Q_NOT_AVAIL idarə olunmur vfio_ap_mdev_reset_queue() funksiyasında növbə sıfırlamasının hələ tamamlanmadığını göstərən dörd hal var ki, bu zaman sıfırlama əməliyyatının tamamlandığını yoxlamaq üçün apq_reset_check() iş növbəsinə (work queue) əlavə edilir. Bu funksiya növbənin statusunu almaq üçün PQAP(TAPQ) funksiyasından istifadə edir və sıfırlamanın tamamlanıb-tamamlanmadığını, uğursuz olub-olmadığını və ya yenidən icra edilməli olduğunu yoxlamaq üçün apq_status_check() funksiyasını çağırır. Yuxarıda Problem #1-də təsvir edildiyi kimi, apq_reset_check() xüsusi olaraq AP_RESPONSE_Q_NOT_AVAIL kodunu yoxlamır, buna görə də potensial olaraq KVM GISC qeydiyyatı və NIB-ni saxlayan sabitləndirilmiş qonaq səhifəsi sıza bilər. Bu, apq_status_check() funksiyasına AP_RESPONSE_Q_NOT_AVAIL üçün bir case operatoru əlavə etmək və həmin hal üçün -ENODEV qaytarmaqla düzəldildi. Çağırıcı olan apq_reset_check() sonra bu geri dönüş kodunu yoxlayacaq və sızmanın qarşısını almaq üçün vfio_ap_free_aqic_resources() funksiyasını çağıracaqdır. Problem 3: ~~~~~~~~~ kvm NULL olduqda vfio_ap_free_aqic_resources() saved_isc resursunu sızdırır vfio_ap_free_aqic_resources() funksiyası kvm_s390_gisc_unregister() çağırışını aşağıdakı şərtlə qoruyur: if (q->saved_isc != VFIO_AP_ISC_INVALID && !WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm))) Əgər matrix_mdev->kvm NULL-dursa — bu, vfio_ap_mdev_unset_kvm() artıq işlədikdə və növbəti təmizləmə yolu bu funksiyaya çatmazdan əvvəl kvm-i təmizlədikdə baş verə bilər — WARN_ON tetiklənir və bütün blok ötürülür. Bu, q->saved_isc dəyişənini etibarsız olmayan bir dəyərdə saxlayır və bu funksiyanın hər hansı növbəti çağırışı zamanı potensial double-free (ikiqat azad etmə) yaradır. Kvm NULL olduqda KVM qonağı artıq ləğv edilmiş olur, ona görə də kvm_s390_gisc_unregister() çağırılmamalıdır və çağırıla bilməz; lakin q->saved_isc həmişə təmizlənməlidir. Bunu kvm_s390_gisc_unregister() çağırışını q->saved_isc sıfırlamasından ayırmaqla düzəldin. WARN_ON indi yalnız matrix_mdev-in NULL olduğu həqiqətən qeyri-mümkün halı qoruyur. NULL kvm, yalnız qeydiyyatdan çıxarma çağırışını ötürməklə problemsiz idarə olunur və saved_isc artıq etibarsız olmadığı hər bir halda q->saved_isc = VFIO_AP_ISC_INVALID şərti qeydsiz olaraq təyin edilir. Əlavə olaraq, növbə hostun AP konfiqurasiyasında olmadıqda vfio_ap_free_aqic_resources() funksiyasını birbaşa çağırmaq üçün vfio_ap_mdev_remove_queue() funksiyasındakı host-konfiqurasiya yoxlamasına else bəndi əlavə edildi. Bu, ehtiyat tədbiri rolunu oynayır: adapter host konfiqurasiyasından silindikdən sonra AP şinası drayverin .remove callback-ini tetiklədikdə, növbə artıq ünvanlana bilmir, beləliklə vfio_ap_mdev_reset_queue ---kəsilib---

CiddilikAşağı
CVSS1.9
İstismar ehtimalı—
MəhsulMicrosoft Azl3 Kernel
Dərc18 okt 2026
İlk görülmə18 okt 2026

Necə düzəltmək olar

Mənbələrdə bu zəiflik üçün düzəldilmiş versiya və ya yamaq keçidi yoxdur.

Təsirlənən məhsullar

MəhsulTəsirlənən versiyalarDüzəldildiyi versiya
microsoft azl3_kernel_6.6.157.1-1Aralıq göstərilməyib—

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-98473 · Microsoft Azl3 Kernel · Dark Radar