CVE-2026-63950

Linux kernel'da aşağıdaki güvenlik açığı giderilmiştir: mm/rmap: try_to_unmap_one fonksiyonunda döngü başlangıcında nr_pages değeri 1 olarak başlatılmalıdır folio_referenced_one() fonksiyonunun yaptığı gibi, her döngü yinelemesinin başında nr_pages değerini 1 olarak başlatın. Bu işlem yapılmadığında, önceki bir folio_unmap_pte_batch() çağrısı tarafından hesaplanan nr_pages değeri, folio_unmap_pte_batch() fonksiyonunun tekrar çalıştırılmadığı sonraki bir yinelemede yeniden kullanılabilir. MAP_ANONYMOUS | MAP_DROPPABLE ile 64K boyutunda büyük bir folio mmap edin, ardından madvise(MADV_FREE) çağrısını yapın ve son sayfayı HMM_DMIRROR_EXCLUSIVE aracılığıyla cihaz-özel (device-exclusive) hale getirin. sysfs üzerinden düğüm geri kazanımını (node reclaim) tetikleyin. Şimdi, try_to_unmap_one() içerisinde, önce lazyfree folio'yu eşleyen 16 girişten ilk 15'ini temizleyeceğiz. Bu durum nr_pages değerini 15 olarak ayarlayacaktır. Bir sonraki pvmw yürütmesinde, bu nr_pages değeri cihaz-özel bir pte üzerinde yeniden kullanılır ve böylece potansiyel olarak folio refcount/mapcount bozulmasına yol açar. Şu anda, çekirdeğin bir izleme kaydı (trace) oluşturmasını sağlayabilen bir kullanıcı alanı programına sahibim ancak çökme folio_referenced_one() içerisinde gerçekleşiyor; çünkü cihaz-özel (device-private) ve rmap etkileşimi arasında mevcut hatalar bulunmaktadır (bunları da araştırıyorum). folio_referenced_one() içerisine girmeyi önlemek için tek satırlık bir çekirdek değişikliği yaptım ve çekirdek, istediğim şekilde try_to_unmap_one içindeki folio_remove_rmap_ptes kısmında çöktü. Hatanın dosya folio gruplamasından değil, lazyfree folio gruplamasından kaynaklandığını unutmayın, çünkü cihaz-özel özelliği yalnızca anonim foliolarda çalışmaktadır. Kullanıcı alanında görünen etki, refcount/mapcount bozulması nedeniyle çekirdeğin herhangi bir yerde çökmesidir.