CVE-2022-48901

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not start relocation until in progress drops are done<br /> <br /> We hit a bug with a recovering relocation on mount for one of our file<br /> systems in production. I reproduced this locally by injecting errors<br /> into snapshot delete with balance running at the same time. This<br /> presented as an error while looking up an extent item<br /> <br /> WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680<br /> CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8<br /> RIP: 0010:lookup_inline_extent_backref+0x647/0x680<br /> RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000<br /> RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001<br /> R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000<br /> R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000<br /> FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0<br /> Call Trace:<br /> <br /> insert_inline_extent_backref+0x46/0xd0<br /> __btrfs_inc_extent_ref.isra.0+0x5f/0x200<br /> ? btrfs_merge_delayed_refs+0x164/0x190<br /> __btrfs_run_delayed_refs+0x561/0xfa0<br /> ? btrfs_search_slot+0x7b4/0xb30<br /> ? btrfs_update_root+0x1a9/0x2c0<br /> btrfs_run_delayed_refs+0x73/0x1f0<br /> ? btrfs_update_root+0x1a9/0x2c0<br /> btrfs_commit_transaction+0x50/0xa50<br /> ? btrfs_update_reloc_root+0x122/0x220<br /> prepare_to_merge+0x29f/0x320<br /> relocate_block_group+0x2b8/0x550<br /> btrfs_relocate_block_group+0x1a6/0x350<br /> btrfs_relocate_chunk+0x27/0xe0<br /> btrfs_balance+0x777/0xe60<br /> balance_kthread+0x35/0x50<br /> ? btrfs_balance+0xe60/0xe60<br /> kthread+0x16b/0x190<br /> ? set_kthread_struct+0x40/0x40<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Normally snapshot deletion and relocation are excluded from running at<br /> the same time by the fs_info-&gt;cleaner_mutex. However if we had a<br /> pending balance waiting to get the -&gt;cleaner_mutex, and a snapshot<br /> deletion was running, and then the box crashed, we would come up in a<br /> state where we have a half deleted snapshot.<br /> <br /> Again, in the normal case the snapshot deletion needs to complete before<br /> relocation can start, but in this case relocation could very well start<br /> before the snapshot deletion completes, as we simply add the root to the<br /> dead roots list and wait for the next time the cleaner runs to clean up<br /> the snapshot.<br /> <br /> Fix this by setting a bit on the fs_info if we have any DEAD_ROOT&amp;#39;s that<br /> had a pending drop_progress key. If they do then we know we were in the<br /> middle of the drop operation and set a flag on the fs_info. Then<br /> balance can wait until this flag is cleared to start up again.<br /> <br /> If there are DEAD_ROOT&amp;#39;s that don&amp;#39;t have a drop_progress set then we&amp;#39;re<br /> safe to start balance right away as we&amp;#39;ll be properly protected by the<br /> cleaner_mutex.