CVE-2026-74632

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: mm/huge_memory: huge_zero_pfn yarış durumu düzeltmesi "mm/huge_memory: fix huge_zero_pfn race", v2 yama serisi. Referans sayımlı huge_zero_folio uygulamasında sinsi bir yarış durumu (race condition) bulunmaktadır. Hızlı yol atomik mantığı, son huge_zero_refcount pinini bırakan shrinker'ın, eşzamanlı çalışan bir get_huge_zero_folio() geçerli bir değer atadıktan sonra shrink_huge_zero_folio_scan() içinde huge_zero_pfn değerinin üzerine ~0UL sentinel değeriyle yazabileceği gerçeğini hesaba katmamaktadır. Bu durum, huge_zero_folio'nun doğru şekilde ayarlanmasına ancak huge_zero_pfn'nin yanlış ayarlanmasına neden olur; sonuç olarak is_huge_zero_pfn() ve dolayısıyla is_huge_zero_pmd(), huge zero folio'yu sıradan bir THP folio olarak yanlış tanımlayacaktır. Bu durum, huge zero folio'nun bölünmesine veya başka şekillerde hatalı işlenmesine yol açabilir. Atomik bir hızlı yol olduğu için çözüm oldukça hassastır ve zayıf sıralamalı mimarilerdeki işlem sıralaması çok dikkatli ele alınmalıdır. İlk commit, hızlı yoldaki yükleme/depolama sıralamasına dikkat ederek huge_zero_[pfn, folio, refcount] yazma işlemi etrafına bir spinlock getirerek sorunu çözer. Bu değişiklik, tek başına geri port edilebilmesi için ilk sıraya yerleştirilmiş ve mümkün olduğunca küçük tutulmuştur. İkinci commit ise kalıcı mantığı dinamik olarak tahsis edilen mantıktan daha iyi ayırmak için CONFIG_PERSISTENT_HUGE_ZERO_FOLIO mantığını yeniden düzenleyen saf bir temizlik çalışmasıdır. Bu yama (2'den 1'si): Eğer !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO ise, huge_zero_folio, huge_zero_refcount tarafından referans sayılır ve mm_get_huge_zero_folio() tarafından döndürülür. Çağıran taraf huge zero sayfa ile işini bitirdiğinde, referans sayısı azaltılır. Yalnızca bir shrinker referans sayısını sıfıra indirebilir. Maalesef, bir shrinker'ın referans sayısını sıfıra indirmesi ile eşzamanlı bir sayfa hatası (page fault) arasında bir yarış durumu oluşabilir. Bunun nedeni, shrink_huge_zero_folio_scan()'in şanssızlık eseri, huge_zero_refcount'u sıfıra ayarlamakla geçersiz bir değer yazmak arasında kesintiye uğrayabilmesidir (preempted). Bu süre zarfında get_huge_zero_folio(), shrink_huge_zero_folio_scan() devam etmeden önce huge_zero_pfn'ye yazabilir. Bu durumda huge zero folio kalıcı olarak yanlış tanımlanacak ve huge zero folio için THP kod yoluna uygunsuz bir şekilde girilmesine neden olacaktır: CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() refcount'u 0 yapar| xchg() huge_zero_folio'yu NULL yapar| get_huge_zero_folio() | | atomic_inc_not_zero() -> sıfır uzun süre kesintiye uğrar | Yeni huge zero folio tahsis et | | Geçerli huge_zero_folio yaz v | Geçerli huge_zero_pfn yaz huge_zero_pfn üzerine ~0UL yazılır <--- Geçersiz üzerine yazma! Bu durum, is_huge_zero_pfn() ve is_huge_zero_pmd()'nin bir huge zero sayfa için yanlışlıkla false döndürmesine neden olur ve bu da huge zero folio'nun hatalı şekilde bölünmesi gibi sorunlara yol açabilir. Sorunun huge_zero_folio değil, huge_zero_pfn ile ilgili olduğuna dikkat edilmelidir; çünkü get_huge_zero_folio(), huge_zero_folio'nun NULL olması şartıyla bir yeniden deneme döngüsü içeren cmpxchg() kullanırken, shrink_huge_zero_folio_scan() huge_zero_folio'yu ayarlamak için xchg() kullanır. huge_zero_folio, huge_zero_pfn ve huge_zero_refcount'un eşzamanlı yazılmasını önlemek için bir spinlock olan huge_zero_lock getirilerek sorun çözülmüştür. Doğruluğu sağlamak için burada büyük özen gösterilmesi gerekir: get_huge_zero_folio() içindeki hızlı yol, kritik bölümün dışında olan atomic_inc_not_zero() kullanır; bu da huge zero tahsisatının sıfır huge_zero_refcount değerine bağlı olduğu anlamına gelir. Hızlı yol huge_zero_lock kullanmaz, dolayısıyla kritik bölüm onun için ilgisizdir. Bu nedenle şu değişmezler gereklidir - huge_zero_refcount ŞUNLARI YAPMALIDIR: * huge_zero_pfn, huge_zero_folio ve ... seri hale getirmeyi sağlamak için yalnızca huge_zero_lock kritik bölümünde ayarlanmalıdır.