diff mbox

[v2] btrfs: tree-checker: Verify block_group_item

Message ID 20180702083414.13670-1-wqu@suse.com (mailing list archive)
State New, archived
Headers show

Commit Message

Qu Wenruo July 2, 2018, 8:34 a.m. UTC
As reported in https://bugzilla.kernel.org/show_bug.cgi?id=199849,
a crafted image with invalid block group items could make free space cache
code to cause panic.

We could early detect such invalid block group item by checking:
1) Size (key)
   We have a up limit on block group item (10G)
2) Chunk objectid
3) Type
   Exactly 1 bit set for type and no more than 1 bit set for profile
4) Used space
   No more than block group size.

This should allow btrfs to detect and refuse to mount the crafted image.

Reported-by: Xu Wen <wen.xu@gatech.edu>
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
changelog:
v2:
  Format change for if() code block, added one new line for each block.
  Use "hweight64() > 1" to detect profile error, replacing the bloated
  !(flags & MASK == 0 || hweight64() == 1) condition.
---
 fs/btrfs/tree-checker.c | 92 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)

Comments

Nikolay Borisov July 2, 2018, 8:37 a.m. UTC | #1
On  2.07.2018 11:34, Qu Wenruo wrote:
> +	if (hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK) > 1) {
> +		block_group_err(fs_info, leaf, slot,
> +"invalid profile flags, have 0x%llx (%lu bits set) expect no more than 1 bit set",
> +			flags & BTRFS_BLOCK_GROUP_PROFILE_MASK,
> +			hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK));

Shouldn't this also be a hweight64() != 1 check ?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Qu Wenruo July 2, 2018, 8:47 a.m. UTC | #2
On 2018年07月02日 16:37, Nikolay Borisov wrote:
> 
> 
> On  2.07.2018 11:34, Qu Wenruo wrote:
>> +	if (hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK) > 1) {
>> +		block_group_err(fs_info, leaf, slot,
>> +"invalid profile flags, have 0x%llx (%lu bits set) expect no more than 1 bit set",
>> +			flags & BTRFS_BLOCK_GROUP_PROFILE_MASK,
>> +			hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK));
> 
> Shouldn't this also be a hweight64() != 1 check ?

What about SINGLE profile on disk?
It doesn't has any profile bit set.

Thanks,
Qu

> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Nikolay Borisov July 2, 2018, 8:49 a.m. UTC | #3
On  2.07.2018 11:47, Qu Wenruo wrote:
> 
> 
> On 2018年07月02日 16:37, Nikolay Borisov wrote:
>>
>>
>> On  2.07.2018 11:34, Qu Wenruo wrote:
>>> +	if (hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK) > 1) {
>>> +		block_group_err(fs_info, leaf, slot,
>>> +"invalid profile flags, have 0x%llx (%lu bits set) expect no more than 1 bit set",
>>> +			flags & BTRFS_BLOCK_GROUP_PROFILE_MASK,
>>> +			hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK));
>>
>> Shouldn't this also be a hweight64() != 1 check ?
> 
> What about SINGLE profile on disk?
> It doesn't has any profile bit set.

Agh, it's implied, doesn't even have a define. Then it's fine I guess,
huhz so many "special cases" ...

Reviewed-by: Nikolay Borisov <nborisov@suse.com>


> 
> Thanks,
> Qu
> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Sterba July 2, 2018, 2:48 p.m. UTC | #4
On Mon, Jul 02, 2018 at 04:34:14PM +0800, Qu Wenruo wrote:
> As reported in https://bugzilla.kernel.org/show_bug.cgi?id=199849,
> a crafted image with invalid block group items could make free space cache
> code to cause panic.
> 
> We could early detect such invalid block group item by checking:
> 1) Size (key)
>    We have a up limit on block group item (10G)

> +	if (key->offset > 10ULL * SZ_1G) {
> +		block_group_err(fs_info, leaf, slot,
> +			"invalid block group size, have %llu expect (0, %llu)",
> +				key->offset, 10ULL * SZ_1G);

Can you please make this magic constant a define and explain in a
comment how it's calculated? Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Qu Wenruo July 3, 2018, 12:56 a.m. UTC | #5
On 2018年07月02日 22:48, David Sterba wrote:
> On Mon, Jul 02, 2018 at 04:34:14PM +0800, Qu Wenruo wrote:
>> As reported in https://bugzilla.kernel.org/show_bug.cgi?id=199849,
>> a crafted image with invalid block group items could make free space cache
>> code to cause panic.
>>
>> We could early detect such invalid block group item by checking:
>> 1) Size (key)
>>    We have a up limit on block group item (10G)
> 
>> +	if (key->offset > 10ULL * SZ_1G) {
>> +		block_group_err(fs_info, leaf, slot,
>> +			"invalid block group size, have %llu expect (0, %llu)",
>> +				key->offset, 10ULL * SZ_1G);
> 
> Can you please make this magic constant a define and explain in a
> comment how it's calculated? Thanks.

Of course, it's used in btrfs_alloc_chunk(), and I'll make it a constant
define.

Thanks,
Qu

> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
diff mbox

Patch

diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
index 8d40e7dd8c30..d4f872682668 100644
--- a/fs/btrfs/tree-checker.c
+++ b/fs/btrfs/tree-checker.c
@@ -353,6 +353,95 @@  static int check_dir_item(struct btrfs_fs_info *fs_info,
 	return 0;
 }
 
+__printf(4, 5)
+__cold
+static void block_group_err(const struct btrfs_fs_info *fs_info,
+			    const struct extent_buffer *eb, int slot,
+			    const char *fmt, ...)
+{
+	struct btrfs_key key;
+	struct va_format vaf;
+	va_list args;
+
+	btrfs_item_key_to_cpu(eb, &key, slot);
+	va_start(args, fmt);
+
+	vaf.fmt = fmt;
+	vaf.va = &args;
+
+	btrfs_crit(fs_info,
+	"corrupt %s: root=%llu block=%llu slot=%d bg_start=%llu bg_len=%llu, %pV",
+		btrfs_header_level(eb) == 0 ? "leaf" : "node",
+		btrfs_header_owner(eb), btrfs_header_bytenr(eb), slot,
+		key.objectid, key.offset, &vaf);
+	va_end(args);
+}
+
+static int check_block_group_item(struct btrfs_fs_info *fs_info,
+				  struct extent_buffer *leaf,
+				  struct btrfs_key *key, int slot)
+{
+	struct btrfs_block_group_item bgi;
+	u32 item_size = btrfs_item_size_nr(leaf, slot);
+	u64 flags;
+
+	/*
+	 * Here we don't really care about unalignment since extent allocator
+	 * can handle it.
+	 * We care more about the size, as if one block group is larger than
+	 * maximum size, it's must be some obvious corruption
+	 */
+	if (key->offset > 10ULL * SZ_1G) {
+		block_group_err(fs_info, leaf, slot,
+			"invalid block group size, have %llu expect (0, %llu)",
+				key->offset, 10ULL * SZ_1G);
+		return -EUCLEAN;
+	}
+
+	if (item_size != sizeof(bgi)) {
+		block_group_err(fs_info, leaf, slot,
+			"invalid item size, have %u expect %lu",
+				item_size, sizeof(bgi));
+		return -EUCLEAN;
+	}
+
+	read_extent_buffer(leaf, &bgi, btrfs_item_ptr_offset(leaf, slot),
+			   sizeof(bgi));
+	if (btrfs_block_group_chunk_objectid(&bgi) !=
+	    BTRFS_FIRST_CHUNK_TREE_OBJECTID) {
+		block_group_err(fs_info, leaf, slot,
+		"invalid block group chunk objectid, have %llu expect %llu",
+				btrfs_block_group_chunk_objectid(&bgi),
+				BTRFS_FIRST_CHUNK_TREE_OBJECTID);
+		return -EUCLEAN;
+	}
+
+	if (btrfs_block_group_used(&bgi) > key->offset) {
+		block_group_err(fs_info, leaf, slot,
+			"invalid block group used, have %llu expect [0, %llu)",
+				btrfs_block_group_used(&bgi), key->offset);
+		return -EUCLEAN;
+	}
+
+	flags = btrfs_block_group_flags(&bgi);
+	if (hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK) > 1) {
+		block_group_err(fs_info, leaf, slot,
+"invalid profile flags, have 0x%llx (%lu bits set) expect no more than 1 bit set",
+			flags & BTRFS_BLOCK_GROUP_PROFILE_MASK,
+			hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK));
+		return -EUCLEAN;
+	}
+
+	if (hweight64(flags & BTRFS_BLOCK_GROUP_TYPE_MASK) != 1) {
+		block_group_err(fs_info, leaf, slot,
+"invalid type flags, have 0x%llx (%lu bits set) expect exactly 1 bit set",
+			flags & BTRFS_BLOCK_GROUP_TYPE_MASK,
+			hweight64(flags & BTRFS_BLOCK_GROUP_TYPE_MASK));
+		return -EUCLEAN;
+	}
+	return 0;
+}
+
 /*
  * Common point to switch the item-specific validation.
  */
@@ -374,6 +463,9 @@  static int check_leaf_item(struct btrfs_fs_info *fs_info,
 	case BTRFS_XATTR_ITEM_KEY:
 		ret = check_dir_item(fs_info, leaf, key, slot);
 		break;
+	case BTRFS_BLOCK_GROUP_ITEM_KEY:
+		ret = check_block_group_item(fs_info, leaf, key, slot);
+		break;
 	}
 	return ret;
 }