diff options
author | David Sterba <dsterba@suse.com> | 2017-08-25 19:08:37 +0200 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2017-09-08 16:15:05 +0200 |
commit | 9b47f18aec5afb87e2271acc2c39cdc698658f7d (patch) | |
tree | edca4228f005054f23030458cff59f2c3fa0fa68 | |
parent | 145a5969bd5c8a276128b54217d0a6459c8a3af8 (diff) |
btrfs-progs: handle blockgroup errors when opening filesystem
The call to btrfs_read_block_groups could loop if the metadata are
damaged (reported eg. for an unaligned block), due to lack of error
handling. We have to check for restored images or currently created
filesystems, that do not contain the blockgroups.
Can be reproduced by fuzzed image bko-155551.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=155551
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
-rw-r--r-- | disk-io.c | 12 |
1 files changed, 10 insertions, 2 deletions
@@ -1041,8 +1041,16 @@ int btrfs_setup_all_roots(struct btrfs_fs_info *fs_info, u64 root_tree_bytenr, fs_info->generation = generation; fs_info->last_trans_committed = generation; if (extent_buffer_uptodate(fs_info->extent_root->node) && - !(flags & OPEN_CTREE_NO_BLOCK_GROUPS)) - btrfs_read_block_groups(fs_info->tree_root); + !(flags & OPEN_CTREE_NO_BLOCK_GROUPS)) { + ret = btrfs_read_block_groups(fs_info->tree_root); + /* + * If we don't find any blockgroups (ENOENT) we're either + * restoring or creating the filesystem, where it's expected, + * anything else is error + */ + if (ret != -ENOENT) + return -EIO; + } key.objectid = BTRFS_FS_TREE_OBJECTID; key.type = BTRFS_ROOT_ITEM_KEY; |