CVE-2026-43118

Orta

Açıklama

Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: btrfs: log yeniden oynatma sonrası sıfır olmayan boyuta sahip sıfır boyutlu inode hatası düzeltildi Yeni bir isim veya bir dizin için yeni dizin girişleri kaydedilmesinin bir parçası olarak, bir inode'un mevcut olduğu kaydedilirken, kaydedilen inode öğesinin neslini (generation) her zaman 0 olarak ayarlarız. Bu, log yeniden oynatma sırasında (overwrite_item() fonksiyonunda), sadece bir inode'un mevcut olduğunu kaydettiğimiz için i_size değerini ayarlamamamız gerektiğini belirtmek içindir; böylece alt hacim ağacındaki (subvolume tree) inode'un i_size değeri korunmalıdır (çünkü yeni isimler veya bir inode'un varlığı kaydedildiğinde extent'ler kaydedilmez). Bu durum, bir inode'u zaten tam modda kaydettiğimizde veya geçmiş bir işlemde oluşturulmuş bir inode'u ilk kez kaydettiğimizde, söz konusu inode'un yeni i_size değeri 0 olduğunda ve ardından inode için yeni bir isim kaydettiğimizde (yeni bir hardlink veya yeniden adlandırma nedeniyle) sorun yaratmaktadır; bu durumda inode için 0 i_size ve 0 nesil kaydedilir, bu da log yeniden oynatma kodunun inode'un i_size değerini 0 olarak güncellememesine neden olur (overwrite_item() içinde). Örnek senaryo: mkdir /mnt/dir xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo sync xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo ln /mnt/dir/foo /mnt/dir/bar xfs_io -c "fsync" /mnt/dir <güç kesintisi> Log yeniden oynatmadan sonra dosya 64K boyutunda kalmaya devam eder. Bunun nedeni, foo dosyasını fsync ile ilk kez kaydettiğimizde mevcut 0 olan i_size değerini kaydetmemiz, ardından bir hard link oluşturduğumuzda inode'u tekrar var olma modunda (LOG_INODE_EXISTS) kaydetmemiz ancak log ağacına eklediğimiz inode öğesi için nesli 0 olarak belirlememizdir; böylece log yeniden oynatma sırasında overwrite_item(), neslin 0 ve i_size'ın 0 olduğunu görür ve inode'un i_size değerini 64K'dan 0'a güncellemeyi atlar. fill_inode_item() fonksiyonunda, eğer inode mevcut işlemde daha önce kaydettiğimiz i_size ile kaydedilmişse, her zaman inode'un gerçek neslini kaydettiğimizden emin olarak bu durum düzeltilmiştir. Ayrıca, önceki bir işlemde oluşturulan bir inode yalnızca var olma modunda kaydedilmişse, commit kökünden bulunan inode öğesinde saklanan i_size değerinin kaydedildiğinden emin olunmuştur; böylece inode'un mevcut olduğu birden fazla kez kaydedilirse doğru i_size değeri elde edilir. fstests için bir test durumu yakında eklenecektir.

ÖnemOrta
CVSS5.5
İstismar olasılığı—
ÜrünLinux Kernel
Yayın6 May 2026
İlk görülme6 May 2026

Nasıl düzeltilir

Güncelleyin
  • linux linux_kernel6.18.24, 6.19.14 ya da sonraki bir sürüm

Etkilenen ürünler

ÜrünEtkilenen sürümlerDüzeltildiği sürüm
linux linux_kernel2.6.30 ≤ v < 6.18.24, 6.19 ≤ v < 6.19.14, 7.06.18.24, 6.19.14
microsoft azl3_kernel_6.6.144.1-1Aralık belirtilmemiş—
microsoft azl3_kernel_6.6.145.2-1Aralık belirtilmemiş—
microsoft azl3_kernel_6.6.137.1-2Aralık belirtilmemiş—
microsoft azl3_kernel_6.6.138.1-1Aralık belirtilmemiş—
microsoft azl3_kernel_6.6.139.1-1Aralık belirtilmemiş—
microsoft azl3_kernel_6.6.141.1-1Aralık belirtilmemiş—
microsoft azl3_kernel_6.6.143.1-1Aralık belirtilmemiş—
microsoft azl3_kernel_6.6.150.1-1Aralık belirtilmemiş—
microsoft azl3_kernel_6.6.152.1-1Aralık belirtilmemiş—
microsoft azl3_kernel_6.6.157.1-1Aralık belirtilmemiş—
microsoft azl3_kernel_6.6.159.1-1Aralık belirtilmemiş—

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-2026-43118 · Linux Kernel · Dark Radar