CVE-2025-38242

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: mm: userfaultfd: userfaultfd_move ve swap cache arasındaki yarış durumu düzeltildi Bu commit, farklı sonuçlar doğurabilen iki tür yarış durumunu (race condition) düzeltmektedir: Barry, c50f8e6053b0 commit'inde bir BUG_ON bildirmiştir; eğer filemap araması NULL dönerse ve ardından folio swap cache'e eklenirse aynı BUG_ON ile karşılaşılabilir. Başka bir yarış durumu tetiklendiğinde (arama sonrası folio değiştiğinde), RSS sayacının bozulduğu görülebilir: [ 406.893936] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0 type:MM_ANONPAGES val:-1 [ 406.894071] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0 type:MM_SHMEMPAGES val:1 Bunun nedeni folionun yanlış VMA'ya kaydedilmesidir. Herhangi bir veri bozulması olup olmayacağından emin değilim, görünüşe göre yok. Ancak yukarıdaki sorunlar halihazırda kritiktir. Bir swap entry PTE gördüğünde, userfaultfd_move kilit gerektirmeyen (lockless) bir swap cache araması yapar ve bulunan folionu hata veren vma'ya taşımaya çalışır. Şu anda, taşınan folionun hala src swap entry'sine ait olduğunu ve swap cache'e yeni bir folio eklenmediğini doğrulamak için PTE değerini kontrol etmeye dayanmaktadır ki bunun güvenilmez olduğu ortaya çıkmıştır. Barry ile swap tablosu serisi üzerinde çalışırken ve inceleme yaparken, mevcut şu yarış durumları gözlemlenmiş ve yeniden üretilmiştir [1]: Aşağıdaki örnekte, move_pages_pte fonksiyonu src_pte'yi dst_pte'ye taşımaktadır; burada src_pte, swap entry S1'i tutan bir swap entry PTE'dir ve S1 swap cache'de değildir: CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Burada entry = S1 olarak alındı ... < kesintiye uğradı > ... <swapin src_pte, folio A tahsis edildi ve kullanıldı> // folio A yeni tahsis edilmiş bir foliodur // ve src_pte içerisine yerleştirilir <swap entry S1 serbest bırakıldı> // src_pte artık folio A'yı işaret ediyor, S1'in // swap sayısı == 0, folio_swap_swap veya swap // ayırıcısının geri kazanımı tarafından serbest bırakılabilir. <başka bir folio B'yi swap out etmeyi dene> // folio B başka bir VMA'daki bir foliodur. <S1 kullanarak folio B'yi swap cache'e koy> // S1 serbest kalmıştı, folio B bunu herhangi bir // sorun olmadan swap out işlemi için kullanabilir. ... folio = filemap_get_folio(S1) // Burada folio B alındı !!! ... < tekrar kesintiye uğradı > ... <folio B swapin edildi ve S1 serbest bırakıldı> // Artık S1 tekrar kullanılmak üzere boşta. <S1 kullanarak src_pte & folio A swapout edildi> // Artık src_pte, tekrar S1'i tutan bir swap entry PTE'dir. folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // Kontrol geçti çünkü src_pte == S1 folio_move_anon_rmap(...) // Geçersiz folio B buraya taşındı !!! Yarış penceresi çok kısadır ve birden fazla nadir olayın çakışmasını gerektirir, bu nedenle gerçekleşme olasılığı çok düşüktür ancak kasıtlı olarak oluşturulmuş bir reprodüksiyon aracı ve artırılmış zaman penceresi ile kolayca yeniden üretilebilir. Bu durum, folio kilidi alındıktan sonra filemap tarafından döndürülen folionun geçerli swap cache foliosu olup olmadığı kontrol edilerek düzeltilebilir. Benzer başka bir yarış durumu da mümkündür: filemap_get_folio NULL döndürebilir, ancak folio (A) aramadan sonra swapin edilebilir ve ardından aynı swap entry kullanılarak tekrar swapout edilebilir. Böyle bir durumda, folio (A) swap cache'de kalmaya devam edebilir, dolayısıyla onun da taşınması gerekir: CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Burada entry = S1 olarak alındı ve S1 swap cache'de değil folio = filemap_get ---kesildi---