CVE-2026-98507

Linux kernel-də aşağıdakı zəiflik aradan qaldırılıb: mm/rmap: anon_vma init və vma->anon_vma publish arasında çatışmayan baryerin düzəldilməsi arm64 serverində, anon_vma kilidini əldə etməyə çalışan tapşırığın hungtask tətiklədiyi aşkar edilmişdir. INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" bu mesajı deaktiv edir. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180 vmcore analiz edildikdən sonra anon_vma->root->rwsem.count dəyərinin -1 olduğu müəyyən edilmişdir. Digər bir anon_vma var ki, onun anon_vma->root->rwsem.count dəyəri 1-dir, anon_vma->root->rwsem.owner kilidin tutulduğunu göstərir, lakin tapşırığın stekində tapşırığın anon_vma kilidini tutmadığı görünür. Əlavə sazlama məlumatları əlavə edildikdən sonra, yaddaş baryerinin olmaması səbəbindən __anon_vma_prepare()-in anon_vma-nı yenidən istifadə etdiyi və anon_vma->root-un UAF (Use-After-Free) xətasını tətiklədiyi aşkar edilmişdir. Bu, iki fərqli anon_vma->root-un kilidlənməsinə və kilidinin açılmasına gətirib çıxarır, nəticədə bir anon_vma heç vaxt kilidini açmır, digər anon_vma isə artıq kilidlənə bilmir. Bu yarış şəraiti (race condition), birləşdirilməmiş, lakin anon_vma ilə uyğun olan iki bitişik VMA tələb edir (məsələn, onlar mprotect() vasitəsilə dəyişdirilə bilən VMA_ACCESS_FLAGS tərəfindən fərqlənirlər). İki axın eyni vaxtda hər bir VMA üzərində xəta verir və hər ikisi yalnız oxuma üçün mmap_lock tutulmuş halda __anon_vma_prepare() funksiyasını çağırır. THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // iki store əməliyyatı yenidən sıralana bilər vma->anon_vma = anon_vma; // A-nın anon_vma-sını tapır anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // hələ də köhnə root-u görə bilər down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // yeni root-u görür, köhnəni heç vaxt açmır up_write(&anon_vma->root->rwsem); A axını səhifə xətası (page fault) tətikləyir və xətalı vma üçün anon_vma hazırlamaq məqsədilə __anon_vma_prepare() funksiyasını çağırır. __anon_vma_prepare() yeni bir anon_vma ayırır və onu ilkinləşdirir, daha sonra adi store əməliyyatı ilə onu vma-ya təqdim edir. anon_vma_prepare() yalnız mmap_lock-un oxuma üçün tutulmasını tələb edir, buna görə də iki axın eyni vaxtda bitişik VMA-larda xəta verə bilər. A axını yeni anon_vma təqdim edərkən, B axını find_mergeable_anon_vma() vasitəsilə həmin anon_vma-nı tapa bilər və sonra anon_vma->root->rwsem-i kilidləyər. anon_vma_alloc()-dakı anon_vma->root-a yazma (store) və vma->anon_vma-ya yazma əməliyyatları yenidən sıralana bilər. anon_vma_lock_write() və spin_lock() yalnız acquire semantikası təmin edir ki, bu da əvvəlki store əməliyyatlarının onlardan sonraya sürüşdürülməsinin qarşısını almır. Müvafiq spin_unlock() və anon_vma_unlock_write()-ın release semantikası çox gec gəlir, vma->anon_vma-ya yazma əməliyyatı onlar təsir göstərməzdən əvvəl artıq yerinə yetirilmiş olur. Nəticədə, B axını aşağıdakı ardıcıllığı müşahidə edə bilər: vma->anon_vma = anon_vma; anon_vma->root = anon_vma; anon_vma slab-ı SLAB_TYPESAFE_BY_RCU-dur, ona görə də yeni ayrılmış anon_vma əvvəllər azad edilmiş birinin yaddaşından istifadə edə bilər. Konstruktor (anon_vma_ctor) anon_vma->root-u sıfırlamır və __put_anon_vma() da onu təmizləmir, beləliklə, köhnə root dəyəri anon_vma_alloc() onu overwrite edənə qədər qalır. Əgər həmin store əməliyyatı...