linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: linux-btrfs@vger.kernel.org
Cc: chris.mason@oracle.com, David Sterba <dsterba@suse.cz>
Subject: [PATCH][RFC] btrfs: fix potential overflow in leafsize accounting
Date: Mon, 13 Jun 2011 19:31:04 +0200	[thread overview]
Message-ID: <1307986264-5707-1-git-send-email-dsterba@suse.cz> (raw)

smatch reported a dead code. It seems to allow wrong item size counting
in leaves, as the first for loop does not adjust the maximum number for
items that would fit in BTRFS_LEAF_DATA_SIZE, and the rest of the code
works with the wrong value. The value of 'nr' is accompanied with
accumulating total_data and total_size, which are compared to the leaf
size and probably prevent this bug to do more harm, but the errorneously
computed value of 'nr' is later used in moving existing items and lastly
for setting up the item for new data.

The bug has a potential to silently corrupt data when leaves are near to
full, though I'm not aware of any related reports so far.

Signed-off-by: David Sterba <dsterba@suse.cz>
---

I haven't tested this yet (thoug I will) because I want to let it out ASAP.


 fs/btrfs/ctree.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index d840893..c4407a6 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -3433,8 +3433,8 @@ int btrfs_insert_some_items(struct btrfs_trans_handle *trans,
 	for (i = 0; i < nr; i++) {
 		if (total_size + data_size[i] + sizeof(struct btrfs_item) >
 		    BTRFS_LEAF_DATA_SIZE(root)) {
-			break;
 			nr = i;
+			break;
 		}
 		total_data += data_size[i];
 		total_size += data_size[i] + sizeof(struct btrfs_item);
-- 
1.7.5.2.353.g5df3e


             reply	other threads:[~2011-06-13 17:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-13 17:31 David Sterba [this message]
2011-06-17 19:18 ` [PATCH][RFC] btrfs: fix potential overflow in leafsize accounting Chris Mason

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=1307986264-5707-1-git-send-email-dsterba@suse.cz \
    --to=dsterba@suse.cz \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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).