CVE-2026-63799

Linux kernel-də aşağıdakı zəiflik aradan qaldırılıb: sched/mmcid: fixup yolunda CID MM_CID_UNSET olduqda OOB clear_bit xətasının düzəldilməsi mm_cid_fixup_cpus_to_tasks() funksiyasında, rq->curr hədəf mm-ə malik olduqda və mm_cid.active təyin edildikdə, keçid biti təyin edilməzdən əvvəl CID cid_in_transit() ilə yoxlanılır. Per-CPU rejimində yeni fork edilmiş və ya exec-ed tapşırıq mm_cid.cid == MM_CID_UNSET ilə işləyə bilər, çünki CID-lər schedule-in zamanı tənbəl şəkildə (lazily) təyin edilir. cid_in_transit() ilə MM_CID_UNSET üçün mühafizə keçir (keçid biti yoxdur), onu MM_CID_UNSET | MM_CID_TRANSIT-ə çevirir və geri saxlayır; daha sonra mm_cid_schedout() bunu bit nömrəsi kimi MM_CID_UNSET ilə clear_bit()-ə ötürür ki, bu da sərhədləri aşan (out-of-bounds) yazmaya səbəb olur. Simptomlar: bu real yaddaş korlanmasıdır, lakin ixtiyari deyil, məhdudlaşdırılmış sərhədləri aşan yazmadır. MM_CID_UNSET sabit sentinel BIT(31)-dir, beləliklə, yanlış dəyər mm_cid_schedout()-ə çatdıqda cid_from_transit_cid() təmizləməsi MM_CID_UNSET-i saxlayır, bu isə "cid < max_cids" konvergensiya testindən keçmir və mm_drop_cid() -> clear_bit(MM_CID_UNSET, mm_cidmask(mm)) hissəsinə düşür. Cid bitmap-i mm_struct slab obyektinə daxil edilib (cpu_bitmap və mm_cpus_allowed-dan sonra) və yalnız num_possible_cpus() bit genişliyindədir, buna görə də 31-ci bitin təmizlənməsi bitmap bazasından 2^31 / 8 == 256 MiB sabit ofsetdə deterministik OOB bit-təmizləməsidir. Ünvan hücumçu tərəfindən idarə olunmur (sabit sentinel -> sabit ofset) və əməliyyat yalnız bir biti təmizləyir; birbaşa xəritənin (direct map) 256 MiB irəlisində nə yerləşirsə, bu, proqnozlaşdırılmayan kernel yaddaşının bir bitini korlayır — bu, ixtiyari ünvan və ya ixtiyari dəyər yazması deyil. Bu, yalnız per-CPU CID rejimində, bir CPU hədəf mm-in cid-i hələ də MM_CID_UNSET olan aktiv tapşırığını işlətdikdə (həmin tapşırığın növbəti schedule-in-i ona real CID təyin etməzdən əvvəlki fork()/execve() pəncərəsi) və per-CPU -> per-task fixup onun üzərindən keçdikdə (thread çıxışı, sched_mm_cid_exit() və ya mm_cid_work_fn()-də gecikdirilmiş max_cids yenidən hesablaması tərəfindən idarə olunan rejim fallback-u) baş verir. Təcrübədə syzkaller bunu __schedule -> mm_cid_switch_to hissəsində hesabat verilmiş KASAN use-after-free kimi üzə çıxarıb, burada problemli clear_bit() mm_cid_schedout() -> mm_drop_cid() vasitəsilə inline edilib. Mövcud cid_in_transit() yoxlamasına əlavə olaraq, keçid bitinin təyinatını MM_CID_UNSET-ə qarşı qoruyun, beləliklə bit yalnız həqiqi tapşırıqa məxsus CID-də təyin ediləcək. İşləyən aktiv tapşırığın CPU-ya məxsus (MM_CID_ONCPU) CID-i yuxarıdakı cid_on_cpu(pcp->cid) budağı tərəfindən idarə olunur və heç vaxt bu yola çatmır, buna görə də MM_CID_UNSET-in (və artıq keçiddə olan halın) istisna edilməsi kifayətdir.