CVE-2026-89772

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: btrfs: veri geri yazımı sırasında folio'ların yazma korumalı hale getirilmesi 095be159f3eb numaralı commit ("btrfs: unify folio dirty flag clearing"), extent_write_cache_pages() içerisindeki folio_clear_dirty_for_io() çağrısını basit bir folio_test_dirty() kontrolü ile değiştirmiştir. folio_clear_dirty_for_io(), kirli bayrağını temizlemenin yanı sıra, folio'yu eşleyen paylaşılan mmap PTE'lerini yazma korumalı hale getiren folio_mkclean() fonksiyonunu da çağırır. Folio'nun son sektöründeki kirli durumunu temizlediğimizde (alt sayfa olmayan durumlar için tek sektör), submit_one_sector() içerisinde hala folio_clear_dirty_for_io() fonksiyonunun çağrıldığına dikkat edilmelidir. Ancak, extent_write_cache_pages() içerisindeki bu erken çağrı kaybedilmiştir. Ek yazma koruması olmadan, dosyayı mmap ile eşlemiş bir işlem; sabit bir folio bekleyen geri yazım işlemleri (sağlama hesaplama, sıkıştırma, kopyalama vb.) sırasında, hata üretmeden bir sektörü değiştirebilir ve bu durum bir dizi somut hataya yol açar. 1. Büyük folio'lar veya alt sayfa sektör boyutları için, tüm folio'yu kapsamadığı bir bio göndermek mümkündür. Bu gerçekleştiğinde, üzerinde folio_clear_dirty_for_io() çağırmadığımız bir folio için yolda olan bir bio olacaktır. Mevcut bir mmap-ed PTE'ye sahip bir görev bu pencerede (hata üretmeden) yazma işlemi yaparsa, bu durum bozulmalara neden olabilir. Yazma işlemi sağlama hesaplama veya yazma işlemi devam ederken gerçekleşirse, geçersiz bir sağlama sonucuna ve daha sonra okuma sırasında bozulma raporlarına yol açabilir. Eğer yazma işlemi sağlama hesaplama/yazma tamamlandıktan sonra ancak son sektörün kirli durumu temizlenmeden önce gelirse, yazma işlemi sayfa önbelleğinde yer alır ancak kirli takibini etkilemez ve folio tamamen gönderilip kirli biti temizlendiğinde kaybolur. Bu durum, fsync() çağrılsa bile yazma işleminin kaybıyla sonuçlanır. 2. Ana extent_writepage() döngüsünden ayrı olarak toplu halde gerçekleştirilen bölge tabanlı (zoned) gönderimler için de bu gönderimlerde sağlama ihlalleri riski bulunmaktadır. Bölge tabanlı yazmalar max_zone_append_size ile sınırlandırılmıştır ve folio'larla hizalanmamıştır, dolayısıyla bir gönderim iki folio'ya yayılabilir. extent_write_cache_pages() içinde işlenen ilk folio, bir sonraki folio'nun kısmi aralığını gönderecek olan extent_write_locked_range() fonksiyonunu çağıracaktır; bu sırada söz konusu folio'nun geri kalanı hala kirli olabilir. Dolayısıyla, gönderilen sektörlerdeki kirli durumun temizlenmesi folio_clear_dirty_for_io() fonksiyonunu çağırmaz ve aynı sorun ortaya çıkar. extent_write_cache_pages() bu toplu gönderilen folio'ları atladığından (önceki folio tarafından gönderim yoluyla zaten geri yazım için işaretlenmişlerdir), ek yazma korumasını lock_delalloc_folios() içerisine eklemeliyiz. 3. Satır içi (inline) genişletmeler için bu durum, satır içi genişletmeyi kopyaladıktan sonra/sırasında ancak folio üzerindeki kirli durumu temizlemeden önce gerçekleşen yazmaların kaybedilmesi riskini oluşturur. 4. EOF'yi kapsayan folio'lar için mmap, EOF sonrası sıfırlanmış baytlarla oynayabilir ve bunların kalıcı hale gelmesine neden olarak gelecekteki hataların bunları sıfırlar yerine yanlış şekilde görmesine yol açabilir. 5. Son olarak, sıkıştırılmış genişletmeler için, onları sıkıştırmak üzere çalışırken folio'ları değiştirme riski vardır ve bu da bozuk sıkıştırılmış verilerle sonuçlanır. Özellikle, run_delalloc_compressed() içerisinde, belirtilen aralıkta btrfs_folio_clamp_clear_dirty() fonksiyonunu çağıracak olan compress_file_range() işlemini BTRFS_COMPRESSION_CHUNK_SIZE (512K) parçalar halinde kuyruğa alıyoruz. Alt sayfa olmayan durumlar için bu her zaman tüm folio'yu güvenli bir şekilde temizleyecektir. Alt sayfa durumunda ise burada yine kısmi bir temizleme riski vardır. Özellikle, 2M'lik bir folio'nun 512K'lık çalışma parçalarına ayrıldığını düşünün; bazı durumlarda, tüm compress_file_range() çalışanları folio'nun tüm kirli bit haritalarını temizleyip folio_clear_dirty_for_io() aşamasına gelmeden önce bir parça üzerinde sıkıştırma işlemi başlayabilir. Gönderim aralıklarının kenarlarındaki büyük folio'lar da benzer şekilde sadece kısmen temizlenme riski altındadır. Bu özel boşluk, aynı serideki ikinci bir yama ile getirilmiştir: commit a4ef54dbb576 ("btrfs: make extent_range_clear_dirty_for_io() to handle sector size < page size cases") Sadece folio_clear çağrısını geri yüklemek yeterli değildir...