CVE-2024-45024

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: mm/hugetlb: hugetlb ve core-mm PT kilitlemesi düzeltildi Yakın zamanda, kod tabanında hugetlb'ye özgü sayfa tablosu yürütme kodunu azaltmak amacıyla, GUP'un ortak sayfa tablosu yürütme kodunun çoğu hugetlb özel durumuna girmeden hugetlb VMA'larını da yürütmesi sağlanmıştır. Ancak bir sayfa tablosu kilitleme detayı gözden kaçırılmıştır: tek bir PMD/PUD kullanılarak eşlenmemiş olan hugetlb folio'ları için sayfa tablosu kilitlemesi. Birden fazla PTE'yi kapsayan bir hugetlb folio'su olduğunu varsayalım (örneğin, 4 KiB temel sayfa boyutuna sahip arm64 üzerinde 64 KiB hugetlb folio'ları). GUP, sayfa tablolarını yürütürken PTE tablo kilidini almak için pte_offset_map_lock() işlemini gerçekleştirecektir. Ancak, bu sayfa tablolarını eşzamanlı olarak değiştiren hugetlb aslında mm->page_table_lock kilidini alacaktır; USE_SPLIT_PTE_PTLOCKS ile kilitler farklılık gösterecektir. Benzer bir durum, USE_SPLIT_PMD_PTLOCKS aktifken birden fazla PMD'yi kapsayan hugetlb folio'larında da meydana gelebilir. Bu sorun [1]'de yeniden üretilebilir, örneğin şu hatayı tetikler: [ 3105.936100] ------------[ cut here ]------------ [ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188 [...] [ 3106.047957] Call trace: [ 3106.049522] try_grab_folio+0x11c/0x188 [ 3106.051996] follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0 [ 3106.055527] follow_page_mask+0x1a0/0x2b8 [ 3106.058118] __get_user_pages+0xf0/0x348 [ 3106.060647] faultin_page_range+0xb0/0x360 [ 3106.063651] do_madvise+0x340/0x598 huge_pte_lockptr()'nin etkili bir şekilde herhangi bir core-mm sayfa tablosu yürütücüsünün kullandığı aynı PT kilitlerini kullanması sağlanmıştır. Bir pte işaretçisi kullanarak PTE sayfa tablosu kilidini elde etmek için ptep_lockptr() eklenmiştir; maalesef CONFIG_HIGHPTE ile sahip olabileceğimiz kmap'li sayfa tabloları ile virt_to_page() çalışmadığından pte_lockptr() dönüştürülememiştir. Örneğin CONFIG_PGTABLE_LEVELS==2 iken PGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE durumunda beklendiği gibi çalışması için ters sırada kontrol yapılarak CONFIG_PGTABLE_LEVELS doğru şekilde işlenmiştir. Bunun neden çalıştığı belgelenmiştir. Çirkin bir durum mevcuttur: iki PTE sayfa tablosu kullanılarak eşlenen 8 MiB hugetlb folio'sunun olduğu powerpc 8xx. hugetlb PMD tablo kilidini almak isterken, core-mm her iki PTE sayfa tablosundan birinin PTE tablo kilidini alacaktır. Bu tür uç durumlarda, her iki kilidin eşleştiğinden emin olmamız gerekir ki bu durum (neyse ki!) SMP desteklemediği ve dolayısıyla bölünmüş PT kilitleri kullanmadığı için 8xx için halihazırda garanti altındadır. [1] https://lore.kernel.org/all/[email protected]/