CVE-2022-49700

Linux kernel-də aşağıdakı zəiflik aradan qaldırılıb: mm/slub: slab deaktivasiyası zamanı çatışmayan TID yeniləmələri əlavə edildi slab_alloc_node() funksiyasındakı sürətli yol (fastpath), TID dəyişmədikcə c->slab-ın sabit olduğunu fərz edir. Lakin hazırda __slab_alloc() funksiyasının iki yerində CPU slab-ı deaktiv edilərkən TID yenilənmir. Əgər çox sayda əməliyyat düzgün şəkildə yarışarsa (race condition), bu, obyektin itməsinə səbəb ola bilər; və ya daha az ehtimal olunan bir vəziyyətdə, obyektin yanlış slab-ın boş siyahısına (freelist) buraxılmasına gətirib çıxara bilər ki, bu da `inuse` sayğacını pozur və nəticədə hələ də slab obyektləri saxlayan səhifənin səhifə bölücüsinə (page allocator) qaytarılmasına səbəb olur. (Mən faktiki olaraq bu hallar üzərində sınaqlar aparmamışam, bu sadəcə koda baxmağa əsaslanır. Bunun üçün test keyslərinin yazılması çətin görünür...) Vəziyyətin uyğunsuzluğuna səbəb olan yarış (hamısı eyni CPU və kmem_cache üzərindəki əməliyyatlardır): - tapşırıq A: do_slab_free() başlayır: - TID oxunur - pcpu freelist oxunur (==NULL) - `slab == c->slab` yoxlanılır (doğrudur) - [PREEMPT A->B] - tapşırıq B: slab_alloc_node() başlayır: - sürətli yol uğursuz olur (`c->freelist` NULL-dur) - __slab_alloc() daxilinə girir - slub_get_cpu_ptr() (preemption-u söndürür) - ___slab_alloc() daxilinə girir - local_lock_irqsave() götürülür - c->freelist NULL kimi oxunur - get_freelist() NULL qaytarır - `c->slab = NULL` yazılır - local_unlock_irqrestore() buraxılır - new_slab etiketini keçir - slub_percpu_partial() NULL-dur - get_partial() NULL qaytarır - slub_put_cpu_ptr() (preemption-u aktivləşdirir) - [PREEMPT B->A] - tapşırıq A: do_slab_free() tamamlanır: - this_cpu_cmpxchg_double() uğurlu olur() - [KORLUP VƏZİYYƏT: c->slab==NULL, c->freelist!=NULL] Buradan sonra, əgər tapşırıq B-yə davam etməyə icazə verilsə, c->freelist-dəki obyekt itəcək: O, retry_load_slab etiketini keçəcək, c->slab-ı təyin edəcək, sonra load_freelist-ə tullanacaq və bu da c->freelist-i sıfırlayacaq. Lakin bunun əvəzinə aşağıdakı kimi davam etsək, daha ciddi korlup baş verir: - tapşırıq A: digər struct slab-dan olan obyekt üzərində __slab_free() işlədir: - CPU_PARTIAL_FREE halı (slab heç bir siyahıda deyildi, indi pcpu partial-dadır) - tapşırıq A: NUMA node məhdudiyyəti ilə slab_alloc_node() işlədir: - sürətli yol uğursuz olur (c->slab NULL-dur) - __slab_alloc() çağırılır - slub_get_cpu_ptr() (preemption-u söndürür) - ___slab_alloc() daxilinə girir - c->slab NULL-dur: new_slab etiketini keçir - slub_percpu_partial() NULL deyil - c->slab slub_percpu_partial(c)-ə təyin edilir - [KORLUP VƏZİYYƏT: c->slab slab-1-ə işarə edir, c->freelist isə slab-2-dən olan obyektlərə malikdir] - redo etiketini keçir - node_match() uğursuz olur - deactivate_slab etiketini keçir - mövcud c->freelist deactivate_slab() funksiyasına ötürülür - slab-2-dən olan obyekti nəzərə almaq üçün slab-1-in inuse sayı azaldılır Bu nöqtədə, slab-1-in inuse sayı olması gərəkəndən 1 vahid azdır. Bu o deməkdir ki, əgər biz slab-1-də biri istisna olmaqla bütün ayrılmış obyektləri azad etsək, SLUB slab-1-in tamamilə istifadə olunmadığını düşünəcək və onun səhifəsini azad edə bilər ki, bu da use-after-free zəifliyinə səbəb olar.