From: Qu Wenruo <wqu@suse.de>
To: Nikolay Borisov <nborisov@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: tree-checker: Verify block_group_item
Date: Mon, 2 Jul 2018 15:34:58 +0800 [thread overview]
Message-ID: <72890e7c-ebfb-7bea-e267-581e908fb8d8@suse.de> (raw)
In-Reply-To: <a317cbc6-8352-9ab2-eb46-cef094d3fd99@suse.com>
On 2018年07月02日 15:28, Nikolay Borisov wrote:
>
>
> On 2.07.2018 08:53, 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)
>> 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>
>> ---
>> fs/btrfs/tree-checker.c | 88 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 88 insertions(+)
>>
>> diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
>> index 8d40e7dd8c30..a42187ba50d7 100644
>> --- a/fs/btrfs/tree-checker.c
>> +++ b/fs/btrfs/tree-checker.c
>> @@ -353,6 +353,91 @@ 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,
> Seems it's not mandatory that this extent buffer points to a leaf, it
> might very well point to an interim node (judging from the
> btrfs_header_level() check in block_group_err). I'd suggest you use the
> more neutral - eb .
Nope, it's ensured to be a leaf.
The caller is only from check_leaf(), whose name explains itself.
>> + 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;
>> + }
>
> Put an empty line after each if to distinguish each part more easily.
>
>> + 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 (!((flags & BTRFS_BLOCK_GROUP_PROFILE_MASK) == 0 ||
>> + hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK) == 1)) {
>
> Can you make this condition a bit more stupid like:
>
> if ((flags & BTRFS_BLOCK_GROUP_PROFILE_MASK) == 0 ||
!=
> hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK) > 1)
In fact, "hweight64() > 1" is good enough.
As all zero and only 1 set bit both fits above check.
I'll use hweight64() only.
>
> It's easy to miss the ! right before the two (( and it causes a mild
> head scratch :)
Yeah, hweight64() > 1 solves all.
Thanks,
Qu
>
>> + 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 +459,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;
>> }
>>
prev parent reply other threads:[~2018-07-02 7:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-02 5:53 [PATCH] btrfs: tree-checker: Verify block_group_item Qu Wenruo
2018-07-02 6:21 ` kbuild test robot
2018-07-02 7:28 ` Nikolay Borisov
2018-07-02 7:34 ` Qu Wenruo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=72890e7c-ebfb-7bea-e267-581e908fb8d8@suse.de \
--to=wqu@suse.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).