CVE-2022-48901

Linux kernel-də aşağıdakı zəiflik aradan qaldırılmışdır: btrfs: davam edən silmə əməliyyatları tamamlanana qədər relocate əməliyyatını başlatmayın İstehsalatda olan fayl sistemlərimizdən birində mount zamanı recover edilən relocate prosesi ilə bağlı xətaya rast gəldik. Mən bunu eyni vaxtda balance işləyərkən snapshot silməsinə xətalar yerləşdirməklə lokal olaraq təkrar etdim. Bu, extent elementinin axtarışı zamanı xəta kimi ortaya çıxdı: WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680 CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8 RIP: 0010:lookup_inline_extent_backref+0x647/0x680 RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000 RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001 R10: 0001434088152de0 R11: 0000000000000000 R12: 00000001d05000 R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000 FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0 Call Trace: <TASK> insert_inline_extent_backref+0x46/0xd0 __btrfs_inc_extent_ref.isra.0+0x5f/0x200 ? btrfs_merge_delayed_refs+0x164/0x190 __btrfs_run_delayed_refs+0x561/0xfa0 ? btrfs_search_slot+0x7b4/0xb30 ? btrfs_update_root+0x1a9/0x2c0 btrfs_run_delayed_refs+0x73/0x1f0 ? btrfs_update_root+0x1a9/0x2c0 btrfs_commit_transaction+0x50/0xa50 ? btrfs_update_reloc_root+0x122/0x220 prepare_to_merge+0x29f/0x320 relocate_block_group+0x2b8/0x550 btrfs_relocate_block_group+0x1a6/0x350 btrfs_relocate_chunk+0x27/0xe0 btrfs_balance+0x777/0xe60 balance_kthread+0x35/0x50 ? btrfs_balance+0xe60/0xe60 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK> Normalda snapshot silinməsi və relocate əməliyyatı fs_info->cleaner_mutex vasitəsilə eyni vaxtda icra olunmaqdan istisna edilir. Lakin, əgər ->cleaner_mutex gözləyən təxirə salınmış balance varsa və snapshot silinməsi icra olunursa, sonra sistem çöksə, biz yarımçıq silinmiş snapshot vəziyyətinə düşürük. Yenə də, normal halda relocate başlamazdan əvvəl snapshot silinməsi tamamlanmalıdır, lakin bu halda relocate çox güman ki, snapshot silinməsi tamamlanmadan başlaya bilər, çünki biz sadəcə kökü dead roots siyahısına əlavə edirik və snapshot-u təmizləmək üçün növbəti cleaner icrasını gözləyirik. Bu problem, əgər təxirə salınmış drop_progress açarı olan hər hansı DEAD_ROOT-lar varsa, fs_info üzərində bir bit təyin etməklə həll edilir. Əgər belədirsə, deməli biz drop əməliyyatının ortasında idik və fs_info üzərində bayraq (flag) təyin edirik. Bundan sonra balance yenidən başlamaq üçün bu bayrağın sıfırlanmasını gözləyə bilər. Əgər drop_progress təyin olunmamış DEAD_ROOT-lar varsa, onda balance-ı dərhal başlatmaq təhlükəsizdir, çünki biz düzgün şəkildə cleaner_mutex tərəfindən qorunacağıq.