CVE-2025-38365

Kritik

Açıklama

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: btrfs: yeniden adlandırmalar ve dizin günlükleme arasındaki yarış durumu düzeltildi Yeniden adlandırma işlemi ile dizin inode günlüklemesi arasında bir yarış durumu bulunmaktadır; eğer bu durum gerçekleşirse ve yeniden adlandırma tamamlanmadan önce sistem çökerse veya güç kaybı yaşanırsa, dosya sistemi bir sonraki kez bağlandığında, günlük yeniden oynatma kodu yeniden adlandırılmakta olan dosyayı silecektir. Bu durum, bu senaryoya yol açan adımların ardışık analizini takip ederek daha iyi açıklanabilir. Başlangıç koşullarını değerlendirelim: 1) İşlem N'deyiz; 2) Geçmiş bir işlemde (< N) oluşturulmuş A ve B dizinlerimiz var; 3) Biri A dizininde diğeri B dizininde olmak üzere 2 sert bağlantısı (hardlink) bulunan bir dosyaya karşılık gelen inode X'imiz var; bunları "A/foo_link1" ve "B/foo_link2" olarak adlandıralım. Her iki sert bağlantı da geçmiş bir işlemde (< N) kalıcı hale getirilmiştir; 4) Tek bir sert bağlantıya sahip olan ve A dizininde bulunan bir dosyaya karşılık gelen inode Y'miz var, bunu "A/bar" olarak adlandıralım. Bu dosya da geçmiş bir işlemde (< N) kalıcı hale getirilmiştir. Dosya kaybına yol açan adımlar şunlardır ve tüm bunlar işlem N altında gerçekleşir: 1) "A/foo_link1" bağlantısı kaldırılır, böylece inode X'in last_unlink_trans alanı btrfs_unlink() -> btrfs_record_unlink_dir() aracılığıyla N olarak güncellenir; 2) Görev A, inode Y için "A/bar"dan "A/baz"a yeniden adlandırma işlemini başlatır, böylece btrfs_rename() fonksiyonuna girilir; 3) Görev A, btrfs_insert_inode_ref() çağrısını yaparak inode Y için yeni BTRFS_INODE_REF_KEY değerini ekler; 4) Yeniden adlandırma aynı dizinde gerçekleştiği için, dizin A'nın inode'unun last_unlink_trans alanını mevcut işlem kimliğine ayarlamayız, yani btrfs_record_unlink_dir() çağrılmaz; 5) Görev A, __btrfs_unlink_inode() çağrıldığında dizin A'daki girişleri (BTRFS_DIR_ITEM_KEY ve BTRFS_DIR_INDEX_KEY öğeleri) kaldırır (aslında dizin indeks öğesi geciktirilmiş bir öğe olarak eklenir ancak etki aynıdır); 6) Şimdi görev A, btrfs_add_link() çağrısını yaparak yeni "A/baz" girişini dizin A'ya eklemeden önce başka bir görev olan görev B, inode X'i günlüklemektedir; 7) Görev B, inode X'in fsync işlemini başlatır ve inode X'i günlükledikten sonra, btrfs_log_inode_parent() aşamasında btrfs_log_all_parents() çağrılır; çünkü inode X, adım 1'de ayarlanmış N değerine sahip bir last_unlink_trans değerine sahiptir; 8) btrfs_log_all_parents() aşamasında, commit root kullanarak inode X'in tüm üst dizinlerini ararız, böylece A ve B dizinlerini bulur ve onları günlükleriz. Ancak dizin A günlüklenirken, artık inode Y için ne eski isim olan "A/bar" ne de yeni isim olan "A/baz" için bir dizin indeks öğemiz yoktur; çünkü yeniden adlandırma işlemi eski ismi silmiş ancak henüz yenisini eklememiştir - görev A bunu yapmak için henüz btrfs_add_link() çağırmamıştır. Dizin A'nın günlüklenmesinin bir işlem onaylamasına (transaction commit) geri dönmediğini unutmayın çünkü last_unlink_trans değeri mevcut işlem kimliğinden daha düşüktür (bkz. adım 4); 9) Görev B, A ve B dizinlerini günlüklemeyi bitirir ve günlük ağacını kalıcı hale getirmek için btrfs_sync_log() çağrısının yapıldığı btrfs_sync_file() kısmına döner; 10) Görev B günlük ağacını başarıyla kalıcı hale getirir, btrfs_sync_log() başarıyla tamamlanır ve bir güç kaybı meydana gelir. Inode Y için herhangi bir dizin girişi olmayan bir günlük ağacımız vardır, bu nedenle günlük yeniden oynatma kodu, günlük ağacında mevcut olmadığı ve günlük ağacı kendi indeksi için yetkili olduğu için subvolume ağacından inode Y'ye ait "A/bar" girişini siler ( "A/bar"a karşılık gelen dentry için indeks aralığını kapsayan bir BTRFS_DIR_LOG_INDEX_KEY öğesini günlükledik). Inode Y için başka bir sert bağlantı olmadığı ve günlük yeniden oynatma kodu "A/bar" ismini sildiği için dosya kaybolur. Eğer görev B, günlüğü yalnızca görev A, inode Y için yeni ismi ("A/baz") güncelleyecek olan btrfs_log_new_name() çağrısından sonra senkronize etseydi bu sorun oluşmazdı. Bu sorun, eski dizin girişi kaldırılmadan önce yeniden adlandırmalar sırasında günlük kökü sabitlenerek (pinning) ve ardından serbest bırakılarak çözülmüştür.

ÖnemKritik
CVSS9.1
İstismar olasılığı29. yüzdelik%0,4
ÜrünLinux Kernel
Yayın25 Tem 2025
İlk görülme25 Tem 2025

Nasıl düzeltilir

Güncelleyin
  • linux linux_kernel6.1.143, 6.6.96, 6.12.36, 6.15.5 ya da sonraki bir sürüm

Etkilenen ürünler

ÜrünEtkilenen sürümlerDüzeltildiği sürüm
linux linux_kernel5.18 ≤ v < 6.1.143, 6.2 ≤ v < 6.6.96, 6.7 ≤ v < 6.12.36, 6.13 ≤ v < 6.15.5, 6.166.1.143, 6.6.96, 6.12.36, 6.15.5
debian debian_linux11.0—

Sürümünüzü kontrol edin

Ürünü seçin ve kullandığınız sürümü yazın; sürümün etkilenen aralıkta olup olmadığını görün.

Intelligence 360 paketinde

Attack Surface Management

Alan adlarınıza bağlı varlıkları, bu varlıklarda çalışan teknolojileri ve bilinen zafiyetleri tek listede görün.

CVE-2025-38365 · Linux Kernel · Dark Radar