CVE-2026-68167
Təsvir
Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: btrfs: məlumatların yerini dəyişdirən (data reloc) inode-lar üçün sıxılma tətbiq etməyin [SƏHV] syzbot hesabatına görə, get_new_location() daxilindəki yoxlama tətiklənib: BTRFS info (device loop0): found 31 extents, stage: move data extents BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607 item 0 key (256 INODE_ITEM 0) itemoff 3835 itemsize 160 inode generation 5 transid 0 size 0 nbytes 0 block group 0 mode 40755 links 1 uid 0 gid 0 rdev 0 sequence 0 flags 0x0 atime 1669132761.0 ctime 1669132761.0 mtime 1669132761.0 otime 0.0 item 1 key (256 INODE_REF 256) itemoff 3823 itemsize 12 index 0 name_len 2 item 2 key (258 INODE_ITEM 0) itemoff 3663 itemsize 160 inode generation 1 transid 16 size 733184 nbytes 106496 block group 0 mode 100600 links 0 uid 0 gid 0 rdev 0 sequence 24 flags 0x18 item 3 key (258 EXTENT_DATA 0) itemoff 3595 itemsize 68 generation 16 type 0 inline extent data size 47 ram_bytes 4096 compression 1 [...] item 27 key (18446744073709551611 ORPHAN_ITEM 258) itemoff 2376 itemsize 0 BTRFS error (device loop0): unexpected non-zero offset in file extent item for data reloc inode 258 key offset 0 offset 9277520992061368337 ------------[ cut here ]------------ btrfs_abort_should_print_stack(__error) [SƏBƏB] Yuxarıdakı ağac strukturu göstərir ki, ilk fayl extent elementi "inlined" vəziyyətdədir, bu isə məlumatların yerini dəyişdirən (data reloc) inode-lar üçün mənasızdır, çünki belə inode-lar sadəcə məlumat extent-lərinin yerləşdiyi hədəf blokunu (chunk) təmsil edir. Lakin yerini dəyişdirmə yolu hər bir blok üçün öncədən sahə ayırır, sonra onları klaster-klaster şəkildə "dirty" (çirkli) hala gətirir. Blok qrupunun əvvəlində tək bir blokun olması və eyni klasterdə başqa heç bir bloğun olmaması mümkündür. Beləliklə, yerini dəyişdirmə prosesi həmin blok üçün fayl extent-ni öncədən ayıracaq və birinci bloku "dirty" edəcək. Daha sonra yaddaş təzyiqi digər bloklar "dirty"/ayırılmazdan əvvəl data reloc inode-unun geri yazılmasını tələb edir. Nəhayət, 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper") commit-i delalloc ardıcıllığını dəyişdi. Həmin commit-dən əvvəl biz həmişə əvvəlcə NOCOW cəhd edirdik, buna görə də "dirty" edilmiş blok öncədən ayrılmış sahəyə geri yazılır və adi extent kimi görünürdü. Lakin həmin commit ilə biz həmişə əvvəlcə "inline" cəhd edirik və sıxılma məcburi olduğu üçün birinci bloku sıxmağa çalışırıq, sonra isə sıxılmış məlumatları "inline" edirik, nəticədə data reloc ağacında yuxarıda göstərilən "inlined" fayl extent yaranır. Daha sonra get_new_location() funksiyasındakı yoxlama, fayl extent-nin "inlined" olub-olmadığını yoxlamadan fayl ofsetini yoxlayır və bu da yuxarıdakı xətaya səbəb olur. [HƏLL] Məlumatların yerini dəyişdirən (data reloc) inode-lar üçün sıxılmaya icazə verməyin. Data reloc inode ölçüləri həmişə blokla uyğunlaşdırıldığı üçün, sıxılma tətbiq edilmədiyi müddətcə @data_len həmişə ən azı bir blok olacaq və bu da can_cow_file_range_inline() funksiyasının "false" qaytarmasına səbəb olacaq, beləliklə, heç bir "inlined extent" yaradılmayacaq.
Necə düzəltmək olar
- Linux Linux31a62e4ad66313cf1ebaa00c2a17d644a4b87d22, ae4316f332e03e628712e9dfb89f2b7d3c70c21a və ya daha yeni versiya
Təsirlənən məhsullar
| Məhsul | Təsirlənən versiyalar | Düzəldildiyi versiya |
|---|---|---|
| Linux Linux | 3eaf5f082c4cc71dea70bee23355bf63b24df303 ≤ v < 31a62e4ad66313cf1ebaa00c2a17d644a4b87d22, 3eaf5f082c4cc71dea70bee23355bf63b24df303 ≤ v < ae4316f332e03e628712e9dfb89f2b7d3c70c21a, 7.1 | 31a62e4ad66313cf1ebaa00c2a17d644a4b87d22, ae4316f332e03e628712e9dfb89f2b7d3c70c21a |
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.
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.