CVE-2026-89987

Orta

Təsvir

Linux nüvəsində aşağıdakı boşluq aradan qaldırılmışdır: mm/huge_memory: zap zamanı pmd dirty bitinin folioya ötürülməsi zap_huge_pmd_folio() fayl halı üçün pmd young bitini folioya ötürür, lakin dirty bitini ötürmür. pte yolu bunu zap_present_folio_ptes()-də, həmçinin pmd bölünmə yolu isə __split_huge_pmd_locked()-də ötürür. Əksər fayl xəritələnmələri (mappings) üçün bu çatışmazlıq zərərsizdir, çünki paylaşılmış fayl xəritələnməsinə yazma əməliyyatı folioyu kirli edən page_mkwrite() vasitəsilə həyata keçirilir. tmpfs fərqlidir: onun page_mkwrite() funksiyası yoxdur və vma_wants_writenotify() onun üçün yanlışdır (false), buna görə də MAP_SHARED tmpfs xəritələnməsində oxuma xətası (read fault) do_read_fault() vasitəsilə yazıla bilən pmd təyin edir. do_read_fault() fault_dirty_shared_page() funksiyasını çağırmır, buna görə də həmin xəritələnmə vasitəsilə sonrakı store əməliyyatları yalnız pmd-də aparat tərəfindən müəyyən edilən dirty bitini təyin edir və heç vaxt folio_mark_dirty() funksiyasını çağırmır. Xəta nəticəsində ayrılan shmem foliosu aktual (uptodate) kimi qeyd edilir, lakin kirli (dirty) kimi qeyd edilmir (baxın: shmem_get_folio_gfp()-dəki clear bloku), beləliklə PG_dirty heç vaxt təyin olunmur. Belə bir folionun xəritədən çıxarılması — munmap(), və ya proses dayandıqda exit_mmap() — onun üzərinə yazıldığına dair yeganə qeydi itirir, çünki zap_huge_pmd() dirty bitini ötürmədən pmd-ni silir. Sonradan reclaim prosesi təmiz shmem foliosunu görür: shrink_folio_list()-də bütün swap-out bloku "if (folio_test_dirty(folio))" daxilində yerləşir, buna görə də pageout() ötürülür və folio __remove_mapping()-ə düşür. Orada, swap-supported folio üçün folio_is_file_lru() yanlışdır (false), buna görə də kölgə girişi (shadow entry) yaradılmır və __filemap_remove_folio(folio, NULL) sadəcə i_pages slotunu boşaldır. Məlumatlar swap-a yazılmadan azad edilir və həmin indeks üzrə növbəti xəta sıfırlanmış yeni folio qaytarır. Bu, unmap əməliyyatı boyunca MAP_SHARED tmpfs seqmentində vəziyyəti saxlayan istənilən proses üçün səssiz məlumat itkisidir — məsələn, /dev/shm vasitəsilə bir proses nəsildən digərinə ötürülən keş. Bu, folionun PMD-mapped olmasını tələb edir, ona görə də bu problem yalnız shmem THP aktivləşdirildikdə ortaya çıxır (Meta parkında etdiyimiz və çökmələri müşahidə etməyə başladığımız hal budur); THP söndürüldükdə pte yolu dirty bitini düzgün şəkildə ötürür. Həmçinin bu, yalnız swap aktiv olduqda görünür, çünki swap cihazı olmadıqda shmem folioları (hansılar ki, anon LRU-dadır) reclaim tərəfindən ümumiyyətlə skan edilmir, buna görə də təmiz folio heç vaxt silinmir. x86_64 platformasında huge=within_size ilə mount edilmiş tmpfs ilə təkrar istehsal edilmişdir: 2MB-backed bölgədə read-fault törədin, nəticəyən xəritələnmə vasitəsilə məlum bir pattern yazın, munmap edin, cgroup-un reclaim prosesini məcburi başladın, sonra yenidən map edin və oxuyun. Bu yamasız (patch) bölgə sıfırlar kimi oxunur və vmstat zswpout 0 göstərir — məlumatlar swap-a göndərilmək əvəzinə atılıb. Bu yama ilə bölgə düzgün oxunur və səhifələr gözlənilən kimi swap-a göndərilir. huge=never olduqda və ya ilk toxunuş yazma əməliyyatı olduqda, test hər iki halda uğurlu olur.

CiddilikOrta
CVSS5.5
İstismar ehtimalı—
MəhsulMicrosoft Azl3 Kernel
Dərc16 sen 2026
İlk görülmə16 sen 2026

Necə düzəltmək olar

Mənbələrdə bu zəiflik üçün düzəldilmiş versiya və ya yamaq keçidi yoxdur.

Təsirlənən məhsullar

MəhsulTəsirlənən versiyalarDüzəldildiyi versiya
microsoft azl3_kernel_6.6.157.1-1Aralıq göstərilməyib—
microsoft azl3_kernel_6.6.150.1-1Aralıq göstərilməyib—
microsoft azl3_kernel_6.6.152.1-1Aralıq göstərilməyib—
microsoft azl3_kernel_6.6.159.1-1Aralıq göstərilməyib—

Versiyanızı yoxlayın

Məhsulu seçin və istifadə etdiyiniz versiyanı yazın; versiyanın təsirlənən aralıqda olub-olmadığını görün.

Intelligence 360 paketində

Attack Surface Management

Domenlərinizə bağlı aktivləri, onlarda işləyən texnologiyaları və məlum zəiflikləri bir siyahıda görün.