linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Cc: Yoon Jungyeon <jungyeon@gatech.edu>
Subject: Re: [PATCH 2/6] btrfs: tree-checker: Verify dev item
Date: Wed, 13 Mar 2019 11:19:08 +0200	[thread overview]
Message-ID: <cc998f0e-4c23-0732-8be5-f5488f2e8bbb@suse.com> (raw)
In-Reply-To: <20190313085511.23540-3-wqu@suse.com>



On 13.03.19 г. 10:55 ч., Qu Wenruo wrote:
> [BUG]
> For fuzzed image whose DEV_ITEM has invalid total_bytes as 0, then
> kernel will just panic:
>   BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
>   #PF error: [normal kernel read fault]
>   PGD 800000022b2bd067 P4D 800000022b2bd067 PUD 22b2bc067 PMD 0
>   Oops: 0000 [#1] SMP PTI
>   CPU: 0 PID: 1106 Comm: mount Not tainted 5.0.0-rc8+ #9
>   RIP: 0010:btrfs_verify_dev_extents+0x2a5/0x5a0
>   Call Trace:
>    open_ctree+0x160d/0x2149
>    btrfs_mount_root+0x5b2/0x680
> 
> [CAUSE]
> If device extent verification finds a deivce with 0 total_bytes, then it
> assumes it's a seed dummy, then search for seed devices.
> 
> But in this case, there is no seed device at all, causing NULL pointer.
> 
> [FIX]
> Since this is caused by fuzzed image, let's go the tree-check way, just
> add a new verification for device item.
> 
> Reported-by: Yoon Jungyeon <jungyeon@gatech.edu>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=202691
> Signed-off-by: Qu Wenruo <wqu@suse.com>


I had already reviewed the earlier posting of this patch so:

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


> ---
>  fs/btrfs/tree-checker.c | 84 +++++++++++++++++++++++++++++++++++++++++
>  fs/btrfs/volumes.c      |  9 -----
>  fs/btrfs/volumes.h      |  9 +++++
>  3 files changed, 93 insertions(+), 9 deletions(-)
> 
> diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
> index fe3f37c23c29..5ccb4be583ea 100644
> --- a/fs/btrfs/tree-checker.c
> +++ b/fs/btrfs/tree-checker.c
> @@ -594,6 +594,87 @@ int btrfs_check_chunk_valid(struct btrfs_fs_info *fs_info,
>  	return 0;
>  }
>  
> +
> +__printf(4, 5)
> +__cold
> +static void dev_item_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 devid=%llu %pV",
> +		btrfs_header_level(eb) == 0 ? "leaf" : "node",
> +		btrfs_header_owner(eb), btrfs_header_bytenr(eb), slot,
> +		key.objectid, &vaf);
> +	va_end(args);
> +}
> +
> +static int check_dev_item(struct btrfs_fs_info *fs_info,
> +			  struct extent_buffer *leaf,
> +			  struct btrfs_key *key, int slot)
> +{
> +	struct btrfs_dev_item *ditem;
> +	u64 max_devid = max(BTRFS_MAX_DEVS(fs_info), BTRFS_MAX_DEVS_SYS_CHUNK);
> +
> +	if (key->objectid != BTRFS_DEV_ITEMS_OBJECTID) {
> +		dev_item_err(fs_info, leaf, slot,
> +			     "invalid objectid: has=%llu expect=%llu",
> +			     key->objectid, BTRFS_DEV_ITEMS_OBJECTID);
> +		goto error;
> +	}
> +	if (key->offset > max_devid) {
> +		dev_item_err(fs_info, leaf, slot,
> +			     "invalid devid: has=%llu expect=[0, %llu]",
> +			     key->offset, max_devid);
> +		goto error;
> +	}
> +	ditem = btrfs_item_ptr(leaf, slot, struct btrfs_dev_item);
> +	if (btrfs_device_id(leaf, ditem) != key->offset) {
> +		dev_item_err(fs_info, leaf, slot,
> +			     "devid mismatch: key has=%llu item has=%llu",
> +			     key->offset, btrfs_device_id(leaf, ditem));
> +		goto error;
> +	}
> +
> +	/*
> +	 * Since btrfs device add doesn't check device size at all, we could
> +	 * have device item whose size is smaller than 1M which is useless, but
> +	 * still valid.
> +	 * So here we can only check the obviously wrong case.
> +	 */
> +	if (btrfs_device_total_bytes(leaf, ditem) == 0) {
> +		dev_item_err(fs_info, leaf, slot,
> +			     "invalid total bytes: have 0");
> +		goto error;
> +	}
> +	if (btrfs_device_bytes_used(leaf, ditem) >
> +	    btrfs_device_total_bytes(leaf, ditem)) {
> +		dev_item_err(fs_info, leaf, slot,
> +			     "invalid bytes used: have %llu expect [0, %llu]",
> +			     btrfs_device_bytes_used(leaf, ditem),
> +			     btrfs_device_total_bytes(leaf, ditem));
> +		goto error;
> +	}
> +	/*
> +	 * Remaining members like io_align/type/gen/dev_group aren't really
> +	 * utilized.
> +	 * Skip them to make later usage of them easier.
> +	 */
> +	return 0;
> +error:
> +	return -EUCLEAN;
> +}
> +
>  /*
>   * Common point to switch the item-specific validation.
>   */
> @@ -624,6 +705,9 @@ static int check_leaf_item(struct btrfs_fs_info *fs_info,
>  		ret = btrfs_check_chunk_valid(fs_info, leaf, chunk,
>  					      key->offset);
>  		break;
> +	case BTRFS_DEV_ITEM_KEY:
> +		ret = check_dev_item(fs_info, leaf, key, slot);
> +		break;
>  	}
>  	return ret;
>  }
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 0e3822870f1e..0b839ecbe73f 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -4964,15 +4964,6 @@ static void check_raid56_incompat_flag(struct btrfs_fs_info *info, u64 type)
>  	btrfs_set_fs_incompat(info, RAID56);
>  }
>  
> -#define BTRFS_MAX_DEVS(info) ((BTRFS_MAX_ITEM_SIZE(info)	\
> -			- sizeof(struct btrfs_chunk))		\
> -			/ sizeof(struct btrfs_stripe) + 1)
> -
> -#define BTRFS_MAX_DEVS_SYS_CHUNK ((BTRFS_SYSTEM_CHUNK_ARRAY_SIZE	\
> -				- 2 * sizeof(struct btrfs_disk_key)	\
> -				- 2 * sizeof(struct btrfs_chunk))	\
> -				/ sizeof(struct btrfs_stripe) + 1)
> -
>  static int __btrfs_alloc_chunk(struct btrfs_trans_handle *trans,
>  			       u64 start, u64 type)
>  {
> diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
> index ed806649a473..481c012eae79 100644
> --- a/fs/btrfs/volumes.h
> +++ b/fs/btrfs/volumes.h
> @@ -258,6 +258,15 @@ struct btrfs_fs_devices {
>  
>  #define BTRFS_BIO_INLINE_CSUM_SIZE	64
>  
> +#define BTRFS_MAX_DEVS(info) ((BTRFS_MAX_ITEM_SIZE(info)	\
> +			- sizeof(struct btrfs_chunk))		\
> +			/ sizeof(struct btrfs_stripe) + 1)
> +
> +#define BTRFS_MAX_DEVS_SYS_CHUNK ((BTRFS_SYSTEM_CHUNK_ARRAY_SIZE	\
> +				- 2 * sizeof(struct btrfs_disk_key)	\
> +				- 2 * sizeof(struct btrfs_chunk))	\
> +				/ sizeof(struct btrfs_stripe) + 1)
> +
>  /*
>   * we need the mirror number and stripe index to be passed around
>   * the call chain while we are processing end_io (especially errors).
> 

  reply	other threads:[~2019-03-13  9:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-13  8:55 [PATCH 0/6] btrfs: Enhance tree checker and runtime checker to handle the new wave of fuzzed image attack Qu Wenruo
2019-03-13  8:55 ` [PATCH 1/6] btrfs: tree-checker: Verify chunk items Qu Wenruo
2019-03-13  9:19   ` Nikolay Borisov
2019-03-19 14:50   ` David Sterba
2019-03-20  0:46     ` Qu Wenruo
2019-03-20  5:03       ` Qu Wenruo
2019-03-13  8:55 ` [PATCH 2/6] btrfs: tree-checker: Verify dev item Qu Wenruo
2019-03-13  9:19   ` Nikolay Borisov [this message]
2019-03-13  8:55 ` [PATCH 3/6] btrfs: Check the first key and level for cached extent buffer Qu Wenruo
2019-03-13  9:24   ` Nikolay Borisov
2019-03-13  8:55 ` [PATCH 4/6] btrfs: tree-checker: Enhance chunk checker to validate chunk profiler Qu Wenruo
2019-03-13  9:18   ` Nikolay Borisov
2019-03-13  8:55 ` [PATCH 5/6] btrfs: tree-checker: Verify inode item Qu Wenruo
2019-03-13  9:28   ` Nikolay Borisov
2019-03-13  8:55 ` [PATCH 6/6] btrfs: inode: Verify inode mode to avoid NULL pointer dereference Qu Wenruo
2019-03-13  9:41   ` Nikolay Borisov
2019-03-13  9:01 ` [PATCH 0/6] btrfs: Enhance tree checker and runtime checker to handle the new wave of fuzzed image attack Qu Wenruo
2019-03-19 15:34   ` David Sterba

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=cc998f0e-4c23-0732-8be5-f5488f2e8bbb@suse.com \
    --to=nborisov@suse.com \
    --cc=jungyeon@gatech.edu \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@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).