CVE-2026-74674

Linux kernelində aşağıdakı zəiflik həll edilmişdir: mm: birbaşa səhifə cədvəlinin geri qaytarılmasında yanlış flush ünvanını düzəlt zap_pte_range səhifə cədvəlini geri qaytararkən aşağıdakını edir: pte_free_tlb(tlb, pmd_pgtable(pmdval), addr); və bu şərtsiz olaraq yanlışdır: əgər bu kod icra olunursa, addr *həmişə* cədvəlin əhatə etdiyi diapazonun sonundan bir addım sonrasına işarə edir. addr parametri TLB-ni (dəqiq desək, səhifələmə strukturu keşini) boşaltmaq üçün istifadə olunur ki, azad ediləcək cədvələ istinadlar silinsin və bu parametrə əhəmiyyət verən istənilən arxitektura yanlış ünvanı boşaldacaq. (Lakin onlar yenə də düzgün səhifəni azad edəcəklər). Düşünürəm ki, kernelin ümumiyyətlə necə işlədiyi barədə düşünməyə dəyər. Əgər problemli kod sətrinə çatsaq, əvvəlcə PMD qeydini təmizləyəcəyik (1954-cü sətir, zap_empty_pte_table), sonra force_flush təyin edilibsə, gözləyən boşaltmaları icra edəcəyik (tlb_flush_mmu_tlbonly(tlb)), sonra 1979-cu sətirdə təkrar cəhdi atlayacağıq (uf!), və sonra problemli pte_free_tlb çağırışını edəcəyik. *Və ya* pte_free_tlb-dən dərhal əvvəl PMD qeydini təmizləyəcəyik (1983-cü sətir, zap_pte_table_if_empty). Əgər PMD qeydini təmizlədiyimiz anda hər hansı gözləyən boşaltmamız varsa (yəni həqiqətən son səviyyə qeydlərini silmişiksə), onda boşaltma həqiqətən cədvələ bütün istinadları boşaltmalıdır (Linus, şübhəsiz ki, bunun bütün arxitekturalarda belə olacağını düşünür [0]). Təmizləmə anında yığılmış boşaltmamızın olmadığı şərt çox mürəkkəbdir (bütün zap_pte_range funksiyası son dərəcə mürəkkəb idarəetmə axınına malikdir). Əgər pis hal baş verərsə, onda diapazonun sonuncu dəfə boşaldılmasından sonra PMD qeydini təmizləyəcəyik və istənilən CPU (boş) səhifə cədvəlinə istinadı keşləyə bilər. Əgər bu adi oxuma və ya yazma nəticəsində baş verərsə, bu, segfault ilə nəticələnərdi, yəni nadir olardı. Lakin keş spekulyativ olaraq da doldurula bilər. Sonra yanlış ünvanı boşaldacağıq və sonra cədvəli azad edib, bəlkə də yenidən istifadə edəcəyik. x86-də hətta yanlış ünvanın boşaldılması KPTI olmayan Intel sistemlərində işləyir, çünki INVLPG yalnız hədəf ünvan üçün deyil, *bütün* səhifələmə strukturu keşlərini boşaldır. Lakin INVPCID belə etmir və flush_tlb_one_user mövcud olduqda INVPCID-dən istifadə edəcək. Və sonra işimiz bitdi. AMD sistemləri daha həssasdır: biz EFER.TCE bitini qururuq ki, bu da hətta INVLPG-nin yalnız hədəf ünvanı boşaltmasına səbəb olur. Düşünürəm ki, bu, burada bildirilən ripgrep problemindəki nasazlığı düzəldə bilər: https://github.com/BurntSushi/ripgrep/issues/3494 [0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u