CVE-2025-22034

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: mm/gup: hugetlb VMA-ları ilə FOLL_SPLIT_PMD sorğularını rədd et "mm: fixes for device-exclusive entries (hmm)", v2 patch seriyası. make_device_exclusive_range() funksiyasındakı PageTail() çağırışını Willy ilə müzakirə edərkən, bu yaxınlarda [1] aşkar etdim ki, cihaz-eksklyuziv (device-exclusive) idarəetmə THP ilə düzgün işləmir və sistemdə THP aktiv olduqda hmm-tests özü-testlərinin uğursuz olmasına səbəb olur. Daha ətraflı araşdırdıqda məlum oldu ki, hugetlb düzgün şəkildə çəpərlənmir (fenced). Həmçinin uzun müddətdir məni narahat edən bir məsələnin — cihaz-eksklyuziv girişlərin mapcounts ilə qarşılıqlı əlaqəsinin — bu folio-lar cihaz-eksklyuziv PTE-lərə malik olduqda onların miqrasiya/swapout/split/hwpoison idarəetməsini tamamilə pozduğunu anladım. Aşağıdakı proqramdan CONFIG_TEST_HMM aktiv olan nüvədə 1 GiB həcmində səhifələr ayırmaq və onları cihaz-eksklyuziv etmək üçün istifadə edilə bilər. Səhifələr cihaz-eksklyuziv olduqdan sonra, bu folio-lar swap-a çıxarıla bilmir (yaddaşın geri qaytarılmasına nə dərəcədə məcburi şəkildə çalışılmasından asılı olmayaraq proc$pid/smaps_rollup hər zaman 1 GiB RSS göstərəcək) və ZONE_MOVABLE-a qoşulmuş yaddaş bloku olduqda, onu söndürməyə (offline) çalışmaq sonsuz döngəyə girəcək və köçürülə bilən səhifənin miqrasiyasının uğursuz olduğu barədə xəbərdarlıq edəcək. # echo offline > /sys/devices/system/memory/memory136/state # echo online_movable > /sys/devices/system/memory/memory136/state # ./hmm-swap & ... hər şey cihaz-eksklyuziv olana qədər gözləyin # echo offline > /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [ 285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [ 285.209072][T14882] page_owner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774 [ 285.216765][T14882] post_alloc_hook+0x197/0x1b0 [ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280 [ 285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740 [ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540 [ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340 [ 285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0 [ 285.229074][T14882] __handle_mm_fault+0x2b38/0x56a0 [ 285.230822][T14882] handle_mm_fault+0x368/0x9f0 ... Bu seriya indiyə qədər tapdığım bütün problemləri həll edir. Daha geniş yenidən işləmə/təmizləmə olmadan bunu düzəltməyin asan yolu yoxdur. Bu dəyişikliklər tətbiq edildikdən sonra ayrıca göndərəcəyim bir sıra təmizlik işlərim var (bəziləri əvvəllər göndərilib, bəziləri v1 müzakirələrinin nəticəsidir). Arzu edərdim ki, biz bu (mövcud olmayan, none olmayan) saxta-swap girişləri əvəzinə xüsusi mövcud PROT_NONE PTE-lərdən istifadə edə bilək; lakin bu, daim qarşılaşdığımız eyni problemə (boş PTE bitlərinin çatışmazlığına) gətirib çıxarır və digər oxşar saxta-swap girişlərinə baxdıqda görünür ki, artıq gecdir. Bu seriya ilə birlikdə make_device_exclusive() artıq mm/rmap.c faylına aid deyil, lakin onun köçürülməsini başqa vaxta saxlayacağam. Avadanlığın (HW) olmaması səbəbindən bu seriyanı yalnız hmm-tests özü-testləri ilə sınaqdan keçirdim, ona görə də testlərin aparılmasını, xüsusilə iki GPU-nun cihaz-eksklyuziv giriş tələb etməsi arasındakı qarşılıqlı əlaqənin gözlənilən kimi işləyib-işləmədiyini yoxlamağı xahiş edirəm.