From patchwork Mon Jun 13 17:31:04 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Sterba X-Patchwork-Id: 875962 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.4) with ESMTP id p5DHVBHP025282 for ; Mon, 13 Jun 2011 17:31:12 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753704Ab1FMRbI (ORCPT ); Mon, 13 Jun 2011 13:31:08 -0400 Received: from cantor.suse.de ([195.135.220.2]:45237 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753468Ab1FMRbH (ORCPT ); Mon, 13 Jun 2011 13:31:07 -0400 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 1B6BD90847; Mon, 13 Jun 2011 19:31:06 +0200 (CEST) Received: by ds.suse.cz (Postfix, from userid 10065) id 90CFB74978; Mon, 13 Jun 2011 19:31:05 +0200 (CEST) From: David Sterba To: linux-btrfs@vger.kernel.org Cc: chris.mason@oracle.com, David Sterba Subject: [PATCH][RFC] btrfs: fix potential overflow in leafsize accounting Date: Mon, 13 Jun 2011 19:31:04 +0200 Message-Id: <1307986264-5707-1-git-send-email-dsterba@suse.cz> X-Mailer: git-send-email 1.7.5.2.353.g5df3e Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Mon, 13 Jun 2011 17:31:12 +0000 (UTC) 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 --- 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);