CVE-2026-63950

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: mm/rmap: try_to_unmap_one funksiyasında dövrün əvvəlində nr_pages dəyişənini 1-ə bərabər edin folio_referenced_one() funksiyasının etdiyi kimi, hər dövr iterasiyasının əvvəlində nr_pages dəyişənini 1-ə bərabər edin. Bu olmadan, əvvəlki folio_unmap_pte_batch() çağırışı tərəfindən hesablanmış nr_pages, folio_unmap_pte_batch() funksiyasının yenidən işləmədiyi sonrakı iterasiyada təkrar istifadə edilə bilər. MAP_ANONYMOUS | MAP_DROPPABLE ilə 64K ölçülü böyük folio mmap edin, sonra madvise(MADV_FREE) çağırın, daha sonra HMM_DMIRROR_EXCLUSIVE vasitəsilə son səhifəni cihaz üçün eksklüziv (device-exclusive) edin. sysfs vasitəsilə node reclaim prosesini tetikləyin. İndi, try_to_unmap_one() funksiyasında biz əvvəlcə lazyfree folio-nu xəritələyən 16 girişdən ilk 15-ni təmizləyəcəyik. Bu, nr_pages dəyişənini 15-ə təyin edəcək. Növbəti pvmw gəzintisində bu nr_pages cihaz-eksklüziv pte üzərində təkrar istifadə olunur və beləliklə, potensial olaraq folio refcount/mapcount məlumatlarını korlayır. Hazırda mənim nüvənin izini (trace) çıxara bilən istifadəçi sahəsi proqramım var, lakin çökmə folio_referenced_one() funksiyasında baş verir, çünki cihaz-özəl (device-private) və rmap arasındakı qarşılıqlı əlaqədə mövcud xətalar var (bunları da araşdırıram). folio_referenced_one() funksiyasına daxil olmamaq üçün nüvədə bir sətirlik dəyişiklik etdim və nüvə try_to_unmap_one funksiyasındakı folio_remove_rmap_ptes hissəsində çökdü ki, bu da gözlədiyim nəticə idi. Qeyd edin ki, xəta fayl folio batching-dən yox, lazyfree folio batching-dən bəri mövcuddur, çünki cihaz-eksklüziv yalnız anonim foliolarda işləyir. İstifadəçi sahəsində görünən təsir sadəcə refcount/mapcount korlanması səbəbindən nüvənin haradasa çökməsidir.