CVE-2026-23157

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: btrfs: metadata writepages için kirli metadata eşiğinin kesin olarak gerekmemesi [BUG] 1000'den fazla işlemin balance_dirty_pages() fonksiyonunun io_schedule_timeout() kısmında beklediğine, bunun sistemin donmasına ve bir kernel coredump tetiklemesine neden olduğuna dair dahili bir rapor bulunmaktadır. Kernel v6.4 tabanlıdır ancak kök sorun v6.18 öncesindeki tüm upstream kerneller için geçerlidir. [NEDEN] Öncelikle kirli sayfa dengeleme davranışı hakkındaki bilgileri için Jan Kara'dan alıntı yapılmıştır: "Burada aslında rol oynayan şey cgroup kirli limitiydi çünkü cgroup yalnızca küçük miktarda belleğe sahipti ve bu nedenle onun için kirli limiti yaklaşık 16MB idi. Kirli sınırlama (dirty throttling), hiç kimsenin kirli limitinden (önemli ölçüde) daha fazla kirli bellek oluşturmamasını sağlamaktan sorumludur. Bu nedenle, bir görev sayfaları kirletirken periyodik olarak balance_dirty_pages() fonksiyonuna girer ve kirletme işlemini yavaşlatmak için orada uyumasına izin veririz. Sistem zaten kirli limitinin üzerindeyse (küresel olarak veya çalışan görevin bir cgroup'u dahilinde), kirli sayfa sayısı limitin altına düşene kadar görevin balance_dirty_pages()'dan çıkmasına izin vermeyiz." Yani bu özel durumda, daha önce belirttiğim gibi, nispeten küçük miktarda belleği olan ve sonuç olarak kirli limiti 16MB olarak ayarlanmış bir cgroup vardı. Bu cgroup'tan bir görev, btrfs btree inode içinde yaklaşık 28MB değerinde sayfayı kirletmişti ve bunlar pratikte o cgroup'taki tek kirli sayfalardı. Bu durum, söz konusu cgroup'un kirli sayfalarını azaltmanın tek yolunun btrfs btree inode'un kirli sayfalarını geri yazmak (writeback) olduğu ve ancak bundan sonra işlemlerin balance_dirty_pages()'dan çıkabileceği anlamına gelir. Şimdi tekrar btrfs kısmına dönersek; btree_writepages(), kirli btree inode sayfalarının geri yazılmasından sorumludur. Buradaki sorun şudur: Eğer btree inode'un kirli baytları 32M eşiğinin altındaysa herhangi bir geri yazma işlemi yapmayan dahili bir btrfs eşiği vardır. Bu davranış, mümkün olduğunca çok metadatayı toplu hale getirerek ağaç bloklarını geri yazmamızı ve ardından başka bir değişiklik için onları tekrar re-COW yapmamızı önlemek içindir. Bu dahili 32MiB değeri, mevcut kirli sayfa boyutundan (28MiB) daha yüksektir; yani hiçbir geri yazma gerçekleşmeyecektir ve bu da btrfs ile cgroup arasında bir deadlock'a (ölümcül kilitlenme) neden olacaktır: - Btrfs, daha fazla kirli sayfa oluşana kadar btree inode'u geri yazmak istemez. - Cgroup/MM, btrfs btree inode için daha fazla kirli sayfa istemez. Dolayısıyla, o btree inode'a dokunan her işlem, kirli sayfa sayısı azalana kadar uyku moduna alınır. Kök neden analizi için Jan Kara'ya çok teşekkürler. [İYİLEŞTİRME] b55102826d7d ("btrfs: set AS_KERNEL_FILE on the btree_inode") numaralı kernel commit'inden beri, btrfs btree inode sayfaları yalnızca btrfs'in 32MiB eşiğinden çok daha büyük bir limite sahip olması gereken root cgroup'a faturalandırılacaktır. Bu nedenle yeni kerneller etkilenmemelidir. Ancak mevcut tüm LTS kerneller bu sorundan etkilenmektedir ve AS_KERNEL_FILE özelliğinin tamamını backport etmek iyi bir fikir olmayabilir. Yeni kerneller için bile, çoğu durumda cgroup/MM'nin tam sistem bellek kullanımı hakkında btrfs'in sabit eşiğinden daha iyi bir görünüme sahip olduğunu düşündüğüm için btree_writepages() üzerindeki dahili eşikten kurtulmanın iyi bir fikir olduğu kanaatindeyim. zaten dahili eşik kontrolü yapan btrfs_btree_balance_dirty() fonksiyonunu kullanan dahili çağrıcılar için onları rahatsız etmemize gerek yoktur. Ancak btree_writepages() fonksiyonunun harici çağrıcıları için, btree inode kirli sayfa dengelemesindeki bu tür deadlock'lardan kaçınmak adına dahili btrfs eşiğini görmezden gelip isteklerine uymak ve istedikleri her şeyi geri yazmak gerekir.