| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2022-48901: btrfs: do not start relocation until in progress drops are done |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| btrfs: do not start relocation until in progress drops are done |
| |
| We hit a bug with a recovering relocation on mount for one of our file |
| systems in production. I reproduced this locally by injecting errors |
| into snapshot delete with balance running at the same time. This |
| presented as an error while looking up an extent item |
| |
| 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: 0000000001d05000 |
| 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> |
| |
| Normally snapshot deletion and relocation are excluded from running at |
| the same time by the fs_info->cleaner_mutex. However if we had a |
| pending balance waiting to get the ->cleaner_mutex, and a snapshot |
| deletion was running, and then the box crashed, we would come up in a |
| state where we have a half deleted snapshot. |
| |
| Again, in the normal case the snapshot deletion needs to complete before |
| relocation can start, but in this case relocation could very well start |
| before the snapshot deletion completes, as we simply add the root to the |
| dead roots list and wait for the next time the cleaner runs to clean up |
| the snapshot. |
| |
| Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's that |
| had a pending drop_progress key. If they do then we know we were in the |
| middle of the drop operation and set a flag on the fs_info. Then |
| balance can wait until this flag is cleared to start up again. |
| |
| If there are DEAD_ROOT's that don't have a drop_progress set then we're |
| safe to start balance right away as we'll be properly protected by the |
| cleaner_mutex. |
| |
| The Linux kernel CVE team has assigned CVE-2022-48901 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Fixed in 5.15.27 with commit 6599d5e8bd758d897fd2ef4dc388ae50278b1f7e |
| Fixed in 5.16.13 with commit 5e70bc827b563caf22e1203428cc3719643de5aa |
| Fixed in 5.17 with commit b4be6aefa73c9a6899ef3ba9c5faaa8a66e333ef |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2022-48901 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| fs/btrfs/ctree.h |
| fs/btrfs/disk-io.c |
| fs/btrfs/extent-tree.c |
| fs/btrfs/relocation.c |
| fs/btrfs/root-tree.c |
| fs/btrfs/transaction.c |
| fs/btrfs/transaction.h |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/6599d5e8bd758d897fd2ef4dc388ae50278b1f7e |
| https://git.kernel.org/stable/c/5e70bc827b563caf22e1203428cc3719643de5aa |
| https://git.kernel.org/stable/c/b4be6aefa73c9a6899ef3ba9c5faaa8a66e333ef |