CVE-2025-37964
Açıklama
Linux kernel içerisinde aşağıdaki güvenlik açığı giderilmiştir: x86/mm: TLB temizlemelerinin yanlışlıkla atlanabileceği pencere ortadan kaldırıldı Özetle: mm değiştirme kodunda, yeni CR3'ün ayarlandığı ve CPU'nun yeni mm için TLB temizlemeleri alması gereken bir pencere bulunmaktadır. Ancak should_flush_tlb() fonksiyonundaki bir hata nedeniyle bu temizleme işlemi engellenmektedir. Bu durum, should_flush_tlb() fonksiyonunun IPI gönderdiği pencerenin genişletilmesiyle düzeltilmiştir. Detaylı Versiyon: === Geçmiş === Bu duruma yol açan birkaç olay gerçekleşmiştir. İlk olarak, mm_cpumask() güncellemesinin çok maliyetli olduğu gözlemlenmiş ve bu işlem daha "lazy" hale getirilmiştir. Ancak bu yaklaşım, artık lazy olan mm_cpumask() nedeniyle CPU'lara çok fazla gereksiz IPI gönderilmesine neden olmuştur. Bunun üzerine mm_cpumask()'ı periyodik olarak budamak için kod eklenmiştir[2]. Fakat bu budama işlemi biraz fazla agresif olmuş ve TLB temizlemelerine ihtiyaç duyan CPU'lara gönderimlerin atlanmasına yol açmıştır. Sonuç olarak tekrar aynı noktaya gelinmiştir. === Sorun === should_flush_tlb() içerisindeki aşırı agresif kod şu pencerede devreye girmektedir: // Bu CPU/mm kombinasyonu için IPI'ları etkinleştir, ancak sadece // should_flush_tlb() onaylarsa: cpumask_set_cpu(cpu, mm_cpumask(next)); next_tlb_gen = atomic64_read(&next->context.tlb_gen); choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); load_new_mm_cr3(need_flush); // ^ 'need_flush' false olarak ayarlandıktan sonra, bu CPU'ya // IPI'lar GÖNDERİLMELİDİR ve görmezden gelinmemelidir. this_cpu_write(cpu_tlbstate.loaded_mm, next); // ^ should_flush_tlb() ancak bu noktada true olur! should_flush_tlb(), load_new_mm_cr3() ile 'loaded_mm' yazımı arasındaki sürede TLB temizlemelerini engelleyecektir; oysa burası temizlemelerin engellenmemesi gereken bir penceredir. === Çözüm === Neyse ki, belirsiz olan "CR3'ü yazmak üzere" penceresi zaten loaded_mm==LOADED_MM_SWITCHING ile işaretlenmiştir. should_flush_tlb() içerisinde bu durumun kontrol edilmesi, CPU'nun bir IPI hedefi olduğundan emin olmak için yeterlidir. Bu durum daha fazla TLB temizleme IPI'sine neden olacaktır. Ancak pencere nispeten küçüktür ve bunun ölçülebilir herhangi bir performans etkisine yol açmasını beklemiyorum. LOADED_MM_SWITCHING yazılan yorum, başka bir kullanıcı daha eklendiği için güncellenmiştir. Peter Z ayrıca should_flush_tlb() fonksiyonunun, 'loaded_mm' ve 'is_lazy' değerlerini switch_mm_irqs_off() tarafından yazıldıkları sırayla görmeyebileceğine dair bir endişe dile getirmiştir. Bunların yazıldıkları sırada görüldüğünden emin olmak için bir bariyer (barrier) eklenmiştir.
Nasıl düzeltilir
- linux linux_kernel5.15.183, 6.1.139, 6.6.91, 6.12.29, 6.14.7 ya da sonraki bir sürüm
Etkilenen ürünler
| Ürün | Etkilenen sürümler | Düzeltildiği sürüm |
|---|---|---|
| linux linux_kernel | 5.15.179 ≤ v < 5.15.183, 6.1.129 ≤ v < 6.1.139, 6.6.79 ≤ v < 6.6.91, 6.12.16 ≤ v < 6.12.29, 6.13.4 ≤ v < 6.14.7, 6.15 | 5.15.183, 6.1.139, 6.6.91, 6.12.29, 6.14.7 |
| debian debian_linux | 11.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.
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.