CVE-2024-27080

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: btrfs: fiemap sırasında delalloc aralıklarının tespit edilmesindeki yarış durumu düzeltildi Fiemap için yakın zamanda, fiemap tamponunun aynı dosyanın bellek eşlemeli bir aralığı olduğu senaryolarda bir kilitlenme (deadlock) durumunu önlemek amacıyla, hedef extent aralığının tüm fiemap çağrısı süresince kilitlenmesi işlemi durdurulmuştur. Bu kullanım durumu pratikte pek olası değildir ancak fuzz testiyle (syzbot vb.) tetiklenebilir. Ancak bu durum, şu anda boşluk (hole) olan dosya bölgeleri için delalloc aralıklarının kaçırılmasına neden olan bir yarış durumu (race condition) ortaya çıkarmıştır; böylece fiemap çağıran taraf, bazı dosya bölgeleri için veri olduğundan haberdar olmayacaktır. Bu, bazı kullanım durumları için oldukça ciddi olabilir - örneğin 9.0 öncesi coreutils sürümlerinde, cp programı kaynak dosyadaki boşlukları ve verileri tespit etmek için fiemap kullanıyor ve boşlukları korumak adına sadece veri içeren bölgeleri (extent veya delalloc) kaynak dosyadan hedef dosyaya kopyalıyordu (--sparse komut satırı seçeneği belgelerine bakınız). Bu, eğer cp, bir boşlukta delalloc bulunan bir kaynak dosya ile kullanılırsa ve aşağıda açıklanan yarış durumu gerçekleşirse, hedef dosyanın bu veriler olmadan sonuçlanabileceği anlamına gelir ki bu da etkili olarak bir veri kaybı sorunudur. Yarış durumu şu şekilde gerçekleşir: 1) Şu anda bir boşluk olan [64M, 65M[ dosya aralığında delalloc bulunan bir dosya için, FIEMAP_FLAG_SYNC bayrağı olmadan fiemap çağrılır; 2) Fiemap, inode'u paylaşımlı modda kilitler ve ardından, inode'un io ağacında tüm fiemap hedef aralığını kilitlemeden, dosya extent öğelerini aramak için inode'un alt hacim ağacı üzerinde yineleme yapmaya başlar - bu, b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking") commit'i ile getirilen değişikliktir; söz konusu commit'ten beri yalnızca bir boşluk veya prealloc extent bulduğunda io ağacındaki aralıkları kilitler; 3) Fiemap'in her yaprağı (leaf) kullanmadan önce klonladığı unutulmamalıdır; bu, inode'un io ağacında bir dosya aralığını kilitlerken fiemap tamponunun bir dosyaya bellek eşlemeli olması durumunda kilitlenmeleri önlemek içindir çünkü btrfs_page_mkwrite() ile sayfaya yazmak, sayfanın aralığı için herhangi bir sıralı extent'i bekleyecek ve sıralı extent aralığı kilitlemek isteyip aynı yaprağı değiştirmesi gerekebilecektir, bu da yaprak üzerinde bir kilitlenmeye yol açacaktır; 4) [64M, 65M[ aralığındaki boşluğu bulmadan önce klonlanan yapraktaki dosya extent öğeleri üzerinde yineleme yapılırken, o aralıktaki delalloc temizlenir (flush) ve sıralı extent tamamlanır - yani ilgili dosya extent öğesi inode'un alt hacim ağacındadır ancak fiemap'in üzerinden geçtiği klonlanan yaprakta mevcut değildir; 5) Fiemap, klonlanan yapraktaki boşluğu görerek (veya NO_HOLES özelliği etkin değilse disk_bytenr == 0 olan bir dosya extent öğesi aracılığıyla) [64M, 65M[ aralığındaki boşluğu bulduğunda, inode'un io ağacındaki o dosya aralığını kilitler ve ardından o aralık ve sıralı extent'ler için io ağacındaki EXTENT_DELALLOC bitini kontrol ederek (btrfs_find_delalloc_in_range() ile) delalloc araması yapar. Ancak o aralıktaki delalloc zaten temizlendiği ve sıralı extent tamamlanıp gittiği için hiçbir şey bulamaz - sonuç olarak fiemap, [64M, 65M[ aralığı için delalloc veya bir extent olduğunu raporlamaz, böylece kullanıcı alanı o aralıkta bir boşluk olduğu yanılgısına düşer. Bu durum, aslında fstests'teki generic/094 test vakasıyla ara sıra tetiklenebilir ve eksik bir extent/delalloc aralığını şu şekilde raporlar: generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad) --- tests/generic/094.out 2020-06-10 19:29:03.830519425 +0100 +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 2024-02-28 11:00:00.381071525 +0000 @@ -1,3 +1,9 @@ QA output created by 094 fiemap run with sync fiemap run without sync +ERROR: couldn't find extent at 7 +map is 'HHDDHPPDPHPH' +logical: [ 5.. 6] phys: ---truncated---