CVE-2025-21977

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: fbdev: hyperv_fb: Hyper-V Gen 2 VM-lərdə kdump nüvəsindəki donma probleminin həlli Gen 2 Hyper-V VM-ləri EFI vasitəsilə yüklənir və standart EFI framebuffer cihazına malikdir. Belə bir VM-də kdump nüvəsi işə düşdükdə, framebuffer-ə yanlış yaddaş ünvanı ilə müraciət edildiyi üçün efifb drayverinin yüklənməsi sistemin donmasına səbəb ola bilər. Bu ssenari, orijinal nüvədəki hyperv_fb drayveri artıq işləyən efifb və ya simplefb drayveri ilə konflikt yaratdığı üçün framebuffer-i fərqli bir MMIO ünvanına köçürdükdə baş verir. Sonra hyperv_fb drayveri bu dəyişiklik barədə Hyper-V-ni məlumatlandırır ki, bu da Hyper-V FB VMBus cihaz protokolu tərəfindən icazə verilir. Lakin, kexec əmri kexec_file_load() sistem çağırışı vasitəsilə kdump nüvəsini crash yaddaşına yüklədikdə, sistem çağırışı framebuffer-in köçürüldüyünü bilmir və kdump screen_info-nu orijinal framebuffer ünvanını istifadə edərək qurur. kdump nüvəsinə keçid Hyper-V hostu vasitəsilə baş vermədiyi üçün, Hyper-V yenidən yükləmədə etdiyi kimi framebuffer ünvanını sıfırlamır. efifb işə düşməyə çalışdıqda mövcud olmayan framebuffer ünvanına müraciət edir və bu, Hyper-V hostuna təsir edir. Bu cür çox sayda müraciətdən sonra Hyper-V hostu qonağın bədniyyətli olduğunu düşünür və qonağı elə dərəcədə məhdudlaşdırır ki, o, çox yavaş işləyir və ya donmuş kimi görünür. kdump nüvəsi kexec_load() sistem çağırışı vasitəsilə crash yaddaşına yükləndikdə bu problem baş vermir. Bu halda, kexec əmri /dev/fb0 üzərindən FBIOGET_FSCREENINFO ioctl tərəfindən qaytarılan məlumatlar əsasında screen_info cədvəlini istifadəçi sahəsində özü qurur və bu ona yeni framebuffer yerini verir. Bu problem ilk dəfə 2020-ci ildə bildirilmişdi [1] və nəticədə 3cb73bc3fa2a ("hyperv_fb: Update screen_info after removing old framebuffer") commit-i yaradılmışdı. Bu commit, orig_video_isVGA parametrini 0 olaraq təyin etməklə problemi həll etmişdi, beləliklə kdump nüvəsi EFI framebuffer-dən xəbərdar olmurdu. efifb drayveri yüklənməyə çalışmırdı və heç bir donma baş vermirdi. Lakin 2024-cü ildə c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info") commit-i effektiv şəkildə 3cb73bc3fa2a commit-ini ləğv etdi. c25a19afb81c commit-ində 3cb73bc3fa2a-ya heç bir istinad yoxdur, buna görə də ehtimal ki, bu, 3cb73bc3fa2a ilə bildirilen təsirlər bilinmədən edilib. Hər iki halda, c25a19afb81c commit-indən etibarən orijinal problem yenidən ortaya çıxdı. Maraqlıdır ki, hyperv_drm drayverində bu problem yoxdur, çünki o, framebuffer-i heç vaxt köçürmür. Fərq ondadır ki, hyperv_drm drayveri MMIO ünvanını ayırmazdan *əvvəl* bütün konfliktli framebuffer-ləri silir, hyperv_fb drayveri isə MMIO ünvanını ayırdıqdan *sonra* konfliktli framebuffer-ləri silir. "Sonra" ardıcıllığı ilə hyperv_fb konfliktlə qarşılaşa və framebuffer-i fərqli bir MMIO ünvanına köçürə bilər. Lakin bu konflikt əslində əsassızdır, çünki bir neçə sətir kod sonra silinir. Problemi 2020-ci ildəki 3cb73bc3fa2a commit-indəki yanaşma ilə düzəltmək əvəzinə, hyperv_fb-də addımların ardıcıllığı bir az dəyişdirildi ki, konfliktli framebuffer-lər MMIO ünvanı ayrılmadan əvvəl silinsin. Beləliklə, standart framebuffer MMIO ünvanı hər zaman əlçatan olmalı və kdump nüvəsinin hansı framebuffer ünvanından istifadə etməli olduğu ilə bağlı heç bir qarışıqlıq yaranmamalıdır — bu, hər zaman Hyper-V hostu tərəfindən təmin edilən orijinal ünvandır. Bu yanaşma artıq hyperv_drm drayveri tərəfindən istifadə olunur və modulun başında aperture_remove_conflicting_devices() funksiyası ilə verilən istifadə təlimatlarına uyğundur. Bu yanaşma həmçinin kdump nüvəsini yükləmək üçün kexec_load() istifadə edildikdə yaranan əlaqəli kiçik bir problemi də həll edir. Mövcud kodla, hyperv_fb drayverinin bağlanması (unbind) və yenidən bağlanması (rebind) framebuffer-in yenidən standart framebuffer ünvanına qayıtmasına səbəb ola bilər, çünki yenidən bağlanma zamanı heç bir konflikt olmur. Əgər belə bir köçürmə kdump nüvəsi yeni framebuffer ünvanı ilə yükləndikdən sonra baş verərsə, kdump zamanı yenidən yanlış ünvan ola bilər. Bu problem və onun həlli kdump nüvəsi kontekstində təsvir edilmişdir, lakin bu, həmçinin...