CVE-2026-23077

Linux çekirdeğinde aşağıdaki güvenlik açığı giderilmiştir: mm/vma: mremap() faulted ve unfaulted birleştirme sırasında oluşan anon_vma serbest bırakıldıktan sonra kullanım (UAF) hatası düzeltildi "mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge", v2 yama serisi. 879bca0a2c4f numaralı commit ("mm/vma: fix incorrectly disallowed anonymous VMA merges"), daha önce mümkün olmayan VMA birleştirme senaryolarını gerçekleştirme yeteneği getirmişti. Ancak, faulted bir VMA'nın unfaulted bir VMA ile bitişik olduğu mremap() durumlarında birleştirmeleri yanlış yönetmektedir. Sorunlar üç durumda ortaya çıkmaktadır: 1. Önceki VMA unfaulted: copied -----| v |-----------|.............| | unfaulted |(faulted VMA)| |-----------|.............| prev 2. Sonraki VMA unfaulted: copied -----| v |.............|-----------| |(faulted VMA)| unfaulted | |.............|-----------| next 3. Her iki bitişik VMA da unfaulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| unfaulted | |-----------|.............|-----------| prev next Bu seri, bu vakaların her birini düzeltmekte ve sorunların giderildiğini doğrulamak için kendi kendine testler sunmaktadır. Ayrıca, değişikliklerin doğru çalışmaya devam ettiğini teyit etmek amacıyla halihazırda yönetilen şu durumu da test ettim: 4. prev unfaulted, next faulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| faulted | |-----------|.............|-----------| prev next Bu hata, serinin ilk yamasına bağlantısı verilen bir syzbot raporu aracılığıyla keşfedilmiş olup, bu serinin hatayı düzelttiğini onayladım. Ayrıca yukarıdaki 1-3. durumlarda kopyalanmış bir VMA birleştirilirken, faulted VMA'nın fork edilip edilmediğinin kontrol edilmediğini fark ettim; bu seri söz konusu sorunu da gidermektedir. Bunun çözüldüğünü doğrulamak için kendi kendine testler ekledim (ve testlerin bundan önce başarısız olduğunu onayladım). Bu çalışma kapsamında ayrıca vma_expand() fonksiyonunu temizledim, önceki ismi gereksiz yere kafa karıştırıcı olduğu için vma_had_uncowed_parents() fonksiyonunu vma_is_fork_child() olarak yeniden adlandırdım ve bu fonksiyonla ilgili yorumları sadeleştirdim. Bu yama (4 üzerinden): 879bca0a2c4f numaralı commit ("mm/vma: fix incorrectly disallowed anonymous VMA merges"), daha önce mümkün olmayan VMA birleştirme senaryolarını gerçekleştirme yeteneği getirmişti. Getirilen temel mantık parçası, faulted bir VMA'nın hemen yanındaki unfaulted bir VMA ile birleştirilebilmesiydi ve bu durum anon_vma durumunun doğru şekilde yönetilmesi için dup_anon_vma()'ya dayanıyordu. Mevcut bir VMA'nın birleştirilmesi durumunda (bir VMA'nın özelliklerinin değiştirilmesi ve ardından bu özelliklerin bitişik VMA'lar tarafından paylaşılması durumunda birleştirme yapılması), dup_anon_vma() doğru şekilde çağrılmaktadır. Ancak yeni bir VMA'nın birleştirilmesi durumunda, mremap()'e özgü uç bir durum gözden kaçırılmıştır. Sorun şudur ki; vma_expand(), yalnızca hedef (nihayetinde birleştirilmiş VMA haline gelecek olan VMA) sonraki VMA değilse, yani yeni VMA'nın kurulacağı aralığın ardından gelen VMA değilse dup_anon_vma() işlemini gerçekleştirmektedir. Buradaki kritik nokta, mremap() dışındaki tüm diğer durumlarda, yeni bir VMA birleştirmenin ya mevcut bir VMA'yı genişletmesidir (bu durumda hedef VMA o VMA olacaktır) ya da anon_vma değerinin NULL olmasıdır. Özellikle: * __mmap_region() - yerleşik bir anon_vma yok, başlangıç eşlemesi. * do_brk_flags() - mevcut bir VMA'yı genişletiyor. * vma_merge_extend() - mevcut bir VMA'yı genişletiyor. * relocate_vma_down() - yerleşik bir anon_vma yok, başlangıç eşlemesi. Ek olarak, ne önceki ne de sonraki birleştirilen VMA olan bir VMA'dan anon_vma durumunu çoğaltmamız gereken benzersiz bir durumdayız. dup_anon_vma() sadece target=unfaulted, src=faulted durumuyla ilgilenir. Bu durum, kopyalanan VMA'nın faulted olduğu her vaka için dört olasılık bırakır: 1. Önceki VMA unfaulted: copied -----|