CVE-2026-23077

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılmışdır: mm/vma: mremap() faulted, unfaulted birləşməsində anon_vma UAF xətasını düzəltmək "mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge", v2 yamaq seriyası. 879bca0a2c4f nömrəli commit ("mm/vma: fix incorrectly disallowed anonymous VMA merges") əvvəllər mümkün olmayan VMA birləşmə ssenarilərini reallaşdırmaq imkanını gətirmişdir. Lakin, faulted VMA-nın unfaulted VMA ilə bitişik olduğu mremap() hallarında birləşmələr yanlış idarə olunur. Problemlər üç halda ortaya çıxır: 1. Əvvəlki VMA unfaulted olduqda: copied -----| v |-----------|.............| | unfaulted |(faulted VMA)| |-----------|.............| prev 2. Növbəti VMA unfaulted olduqda: copied -----| v |.............|-----------| |(faulted VMA)| unfaulted | |.............|-----------| next 3. Hər iki bitişik VMA unfaulted olduqda: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| unfaulted | |-----------|.............|-----------| prev next Bu seriya hər bir halı düzəldir və problemlərin həll olunduğunu təsdiqləmək üçün özünütəhlil testləri tətbiq edir. Həmçinin, dəyişikliklərimin düzgün işləməyə davam etdiyini təsdiqləmək üçün artıq həll edilmiş növbəti halı da test etmişəm: 4. prev unfaulted, next faulted: copied -----| v |-----------|.............|-----------| | unfaulted |(faulted VMA)| faulted | |-----------|.............|-----------| prev next Bu xəta syzbot hesabatı vasitəsilə aşkar edilmişdir (seriyanın birinci yamağında link verilmişdir); bu seriyanın xətanı aradan qaldırdığını təsdiqləmişəm. Bundan əlavə, yuxarıdakı 1-3 hallarda kopyalanmış VMA birləşdirilərkən, faulted VMA-nın fork edilmədiyinin yoxlanılmadığını aşkar etdim; bu seriya həmin problemi də həll edir. Bunun həll olunduğunu təsdiqləmək üçün özünütəhlil testləri əlavə etdim (və bu dəyişikliklərdən əvvəl testlərin uğursuz olduğunu təsdiqləmişəm). Həmçinin, bu işin tərkibində vma_expand() funksiyasını optimallaşdırdım, vma_had_uncowed_parents() funksiyasının adını daha anlaşılır olması üçün vma_is_fork_child() olaraq dəyişdirdim və bu funksiya ilə bağlı şərhləri sadələşdirdim. Yamaq (4-dən biri): 879bca0a2c4f nömrəli commit ("mm/vma: fix incorrectly disallowed anonymous VMA merges") əvvəllər mümkün olmayan VMA birləşmə ssenarilərini reallaşdırmaq imkanını gətirmişdir. Tətbiq edilən əsas məntiq, faulted VMA-nı dərhal unfaulted VMA ilə birləşdirmək imkanı idi ki, bu da anon_vma vəziyyətinin düzgün idarə olunması üçün dup_anon_vma() funksiyasından asılıdır. Mövcud VMA-nın birləşdirilməsi halında (VMA-nın xüsusiyyətlərinin dəyişdirilməsi və həmin xüsusiyyətlər bitişik VMA-lar tərəfindən bölüşüldükdə onların birləşdirilməsi), dup_anon_vma() düzgün çağırılır. Lakin yeni VMA-nın birləşdirilməsi halında, mremap()-ə xas olan xüsusi bir künc halı nəzərdən qaçırılmışdı. Problem ondadır ki, vma_expand() yalnız hədəf (sonunda birləşmiş VMA-ya çevriləcək VMA) növbəti VMA olmadıqda (yəni yeni VMA-nın qurulacağı diapazondan sonra gələn VMA olmadıqda) dup_anon_vma() funksiyasını yerinə yetirir. Buradakı əsas məqam odur ki, mremap()-dən başqa bütün digər hallarda yeni VMA birləşməsi ya mövcud VMA-nı genişləndirir (yəni hədəf VMA həmin VMA olur), ya da anon_vma NULL olur. Konkret olaraq: * __mmap_region() - anon_vma yoxdur, ilkin xəritələmə (initial mapping). * do_brk_flags() - mövcud VMA-nın genişləndirilməsi. * vma_merge_extend() - mövcud VMA-nın genişləndirilməsi. * relocate_vma_down() - anon_vma yoxdur, ilkin xəritələmə. Əlavə olaraq, biz anon_vma vəziyyətini nə əvvəlki, nə də növbəti birləşdirilən VMA olmayan bir VMA-dan dublikat etməli olduğumuz unikal vəziyyətdəyik. dup_anon_vma() eksklüziv olaraq target=unfaulted, src=faulted halı ilə məşğul olur. Bu isə kopyalanmış VMA-nın faulted olduğu hər bir hal üçün dörd ehtimal saxlayır: 1. Əvvəlki VMA unfaulted olduqda: copied -----|