CVE-2023-54121

Linux kernel-də aşağıdakı zəiflik aradan qaldırılıb: btrfs: btrfs_drop_extent_map_range funksiyasında yanlış bölünmə düzəldildi İstehsalat mühitində extent_map kodunda, xüsusilə ikinci bölünmə üçün add_extent_mapping() çağırılmalı olduğu zaman btrfs_drop_extent_map_range() funksiyasında müxtəlif WARN_ON() xətaları müşahidə olunurdu. Aşağıdakı extent map strukturunu nəzərə alın: PINNED [0 16K) [32K, 48K) Və sonra skip_pinned == true olmaqla [0, 36K) üçün btrfs_drop_extent_map_range çağırılır. İlkin dövr belə olacaq: start = 0 end = 36K len = 36K Biz [0, 16k) extentini tapacağıq, lakin o PINNED olduğu üçün onu ötürəcəyik, burada bu kod işləyir: start = em_end; if (end != (u64)-1) len = start + len - em_end; Burada em_end 16K-dır, buna görə də indi dəyərlər belədir: start = 16K len = 16K + 36K - 16K = 36K Halbuki len 20K olmalı idi. Bu, növbəti extent [32K, 48K) tapıldıqda problem yaradır; biz [36K, 48k) hissəsini saxlamaq üçün bu extenti bölməliyik, lakin bölünmə kodu belə görünür: split->start = start + len; split->len = em_end - (start + len); Bu halda bizdə: em_end = 48K split->start = 16K + 36K // bu 16K + 20K olmalı idi split->len = 48K - (16K + 36K) // 16K + 36K 52K olduğu üçün burada daşma baş verir Və indi ağacda potensial olaraq extent map-dəki digər girişlərlə üst-üstə düşən etibarsız bir extent_map var. Hətta üst-üstə düşmə olmadığı halda belə, split->start səhv təyin ediləcək ki, bu da bloklarla bağlı bütün hesablamalarda problemlərə səbəb olacaq. Əslində bu dövrdə len-ə ehtiyac yoxdur, son nöqtə kimi sadəcə end istifadə edə bilərik və yalnız ötürülməli olan pinned extent tapdıqda start dəyərini artıra bilərik. Etibarsız extent map daxil edilməsinin qarşısını almaq üçün məntiq bu şəkildə tənzimləndi. skip_pinned yalnız relocate halında istifadə olunur, ona görə də avtomatik relocate aktiv olduqda çox tez-tez baş verə bilən hallar istisna olmaqla, bu nisbətən nadir hadisədir.