CVE-2025-68358

Linux kernel-də aşağıdakı zəiflik aradan qaldırılıb: btrfs: btrfs_clear_space_info_full() funksiyasındakı yarışlı (racy) bit sahəsi yazılması düzəldildi Yaddaş baryerlərinin sıralama zəmanətləri ilə bağlı memory-barriers.txt sənədindən: (*) Bu zəmanətlər bit sahələrinə şamil edilmir, çünki kompilyatorlar çox vaxt bunları dəyişdirmək üçün atomik olmayan oxu-dəyişdir-yaz (read-modify-write) ardıcıllıqları yaradan kodlar generasiya edir. Paralel alqoritmləri sinxronizasiya etmək üçün bit sahələrindən istifadə etməyin. (*) Bit sahələri kilidlər (locks) tərəfindən qorunduğu hallarda belə, verilmiş bir bit sahəsindəki bütün sahələr bir kilidlə qorunmalıdır. Əgər bir bit sahəsindəki iki fərqli sahə müxtəlif kilidlər tərəfindən qorunursa, kompilyatorun atomik olmayan oxu-dəyişdir-yaz ardıcıllıqları bir sahənin yenilənməsi zamanı qonşu sahənin dəyərini korlaya bilər. btrfs_space_info strukturu full, chunk_alloc və flush sahələrindən ibarət olan və eyni alt sözü paylaşan bir bit sahəsinə malikdir: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Buna görə də, kilidlə qorunan bit sahəsi üzvlərindən birinə paralel oxu-dəyişdir-yaz əməliyyatları zamanı yazma itkisinin qarşısını almaq üçün bütün bit sahələrinə yazmalar kiliddən istifadə etməlidir. btrfs_clear_space_info_full() funksiyası istisna olmaqla, digərləri demək olar ki, hamısı bunu edir; həmin funksiya space_infos üzərində dövr edir və tapılan found->full = 0 dəyərini kilidsiz yazır. Təsəvvür edin ki, bir thread block_group silinməsini tamamladığı tranzaksiyanı bitirir və buna görə də btrfs_clear_space_info_full() çağırılır, eyni zamanda məlumatların geri qaytarılması (data reclaim) bileti infrastrukturu do_async_reclaim_data_space() funksiyasını işə salır: T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 Və indi data_sinfo->flush 1-dir, lakin reclaim worker-i çıxıb. Bu, yalnız növbədə gözləyən və ya işləyən iş olmadıqda flush-ın 0 olması invariantını pozur. Bu invariant pozulduqdan sonra, __reserve_bytes() funksiyasına daxil olan gələcək ayırmalar space_info->tickets-ə biletlər əlavə edəcək, lakin space_info->flush-ın 1 olduğunu görüb işi növbəyə əlavə etməyəcək. Bundan sonra onlar nəticədə yaranan bilet üzərində sonsuz gözləyəcəklər, çünki artıq worker-i yenidən aktivləşdirmək qeyri-mümkündür. Mən həmçinin təsirlənən kernel-in assambley koduna baxaraq onun RMW əməliyyatlarını yerinə yetirdiyini təsdiqlədim. Məsələn, flush (3-cü) bitini 0 etmək üçün assambley kodu belədir: andb $0xfb,0x60(%rbx) və oxşar şəkildə full (1-ci) bitini 0 etmək üçün: andb $0xfe,-0x20(%rax) Beləliklə, hesab edirəm ki, bu, praktiki sistemlərdə real bir xətadır. Bir neçə sistemin məhz bu vəziyyətdə olduğunu müşahidə etmişəm, lakin hazırda bunu təkrar istehsal edə bilmirəm. Gələcəkdə problem yaratma ehtimalını aradan qaldırmaq üçün strukturda kifayət qədər yer olduğu və onun onsuz da böyük olduğu faktından istifadə edərək üç bit sahəsi üzvünü bool tipinə dəyişin. Bu, space_info->full yazmalarının digərlərinə təsir etməsinin qarşısını alır.