CVE-2026-63807

Linux kernel-də aşağıdakı zəiflik aradan qaldırılmışdır: KVM: x86/mmu: Maksimum mapping səviyyəsini yoxlamazdan əvvəl hugepage-in slot daxilində olduğundan əmin olun Shadow MMU-da hugepage-ləri bərpa edərkən, shadow səhifənin baza gfn-inin hədəf memslot daxilində olduğunu, shadow səhifənin gfn-i üçün maksimum mapping səviyyəsini sorğulamazdan *əvvəl* təsdiqləyin. GFN-in etibarlılığının öncədən yoxlanılmaması, qonağın memslot sərhədlərindən "aşağıya" doğru genişlənən bir hugepage mapping-i (öz PTE-lərində) yaratdığı halda, slotun lpage_info hissəsinə sərhədlərdən kənar girişə (adətən lpage_info vmalloc ilə ayrıldığı üçün bu, host #PF kimi təzahür edir) səbəb ola bilər. Qonaq üçün yaddaşda xəta (fault) baş verdikdə və qonaq mapping-inin ölçüsü KVM-in (cari) maksimum mapping-indən böyük olduqda, KVM "birbaşa" shadow səhifə yaradır (burada "birbaşa" o deməkdir ki, shadow ediləcək gPTE-lər yoxdur və buna görə də hədəf gfn, shadow səhifənin baza gfn-i əsasında birbaşa hesablanır). Hugepage bərpa axını belə birbaşa shadow səhifələri axtarır, çünki dirty logging zamanı qonaq > host mapping ölçüsü halı yarandıqda 4KiB mapping-ləri məcburi tətbiq edilir. 4KiB məhdudiyyəti götürüldükdə, KVM shadow səhifəni hugepage ilə əvəz edə bilər. Lakin, əgər qonaq hugepage tərəfindən əhatə olunan yaddaş diapazonu memslot sərhədlərini aşdığı üçün KVM ilkin olaraq qonaqdan daha kiçik mapping istifadə etmişdirsə, KVM yaddaşı bərpa etmək üçün istifadə olunan memslot sərhədlərindən kənarda olan gfn-ə malik birbaşa shadow səhifəni bağlayacaqdır. Yarpaq (leaf) mapping üçün əlavə edilmiş rmap girişi düzgün və sərhədlər daxilindədir, lakin yarpaq SPTE-nin valideyn shadow səhifəsinin gfn-i sərhədlərdən kənarda olacaqdır. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK> Potensial hugepage-in sərhədlərini öncədən yoxlamağa ehtiyac yoxdur, yəni, məsələn, sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1)-in də memslot daxilində olduğunu yoxlamayın, çünki kvm_mmu_max_mapping_level() tərəfindən yerinə yetirilən yoxlamalar əsas sərhəd yoxlamalarının genişləndirilmiş formasıdır. Yəni, tam diapazonun öncədən yoxlanılması şübhəli mikro-optimallaşdırma olardı.