summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid Sterba <dsterba@suse.com>2017-08-25 19:08:37 +0200
committerDavid Sterba <dsterba@suse.com>2017-09-08 16:15:05 +0200
commit9b47f18aec5afb87e2271acc2c39cdc698658f7d (patch)
treeedca4228f005054f23030458cff59f2c3fa0fa68
parent145a5969bd5c8a276128b54217d0a6459c8a3af8 (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.c12
1 files changed, 10 insertions, 2 deletions
diff --git a/disk-io.c b/disk-io.c
index ef7633d4..30e656c2 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -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;