Received: by 10.192.165.148 with SMTP id m20csp4176485imm; Mon, 30 Apr 2018 13:14:19 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo94+g+3dwvjSYdbZ/sv9aHPl/4FANKefShf6pL7aF4UWVWyFeygSFaNACN26ttk0EQSVue X-Received: by 2002:a17:902:2c83:: with SMTP id n3-v6mr13874767plb.317.1525119259687; Mon, 30 Apr 2018 13:14:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525119259; cv=none; d=google.com; s=arc-20160816; b=o7AnnSpACW8wvYv6POXYrOe/5gvuBI8fSwn0RBwmEt6QBnC1YgxDRl8yii5IGWJFzG wqfOJnVz1qBDQHh12f/Ws88n0QdlP+7bXyFq6CDtlKiVtYB9tjMjN1dpu4YqgkoSdXGp hKkPxPE7p61WTF4VV0+cFcrbaXcV2frwmd5CQ6cjYHMarxR9J4zamdF+W2WKhut5XkUt 3lSRi4HcHQI75HKCniSoNaglbpctTnjrxAkmG5USnN/VFcLZmfGQrtGw9iFWMkfkWFnW LC2kqlXtP7MXjIBeLLa/lVpWGRQS5bXtVkRAmlxj6iK273y8zjHT4lFYWX4CV7oeL4wD 24VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dmarc-filter :arc-authentication-results; bh=TiY4Wuww0uzUsZP8bc8c2XwVKakHacJn06hYsNRDDsE=; b=TAtgVNh19TdUkMAfxfNeqI7Y6bjiyp7YbWqrHc04QloGPZmCVrj8meP08JOLx9gECG Fr6TPki22HvCgYcSzdko8aWJK82RsCwIs2nPnt0po2yvgUDvjtWYaYJzc5/ggtgL42E9 l8XzrSKCmFr8iYR3zlkjPrNebBQiSQE6Sehe7X9Bf//P3Vs+UK/FFK8uKkCxdRFZb7fK XsZNXCGhJBzZJ2jZQMK9zdtq7HB/hTp5gnfT+lOlSWEC6d2GCkJlOI8qGKlLbUzv43lo 37vLYiNjtFADVXd24pOVrQD7wcPWtCjRjr7EqeN+elb/09ZeMlRSzoZG2f4O7rOyWtUr fhbw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a25-v6si6687778pgf.501.2018.04.30.13.14.05; Mon, 30 Apr 2018 13:14:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755276AbeD3UN4 (ORCPT + 99 others); Mon, 30 Apr 2018 16:13:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:33252 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932128AbeD3T1H (ORCPT ); Mon, 30 Apr 2018 15:27:07 -0400 Received: from localhost (unknown [104.132.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 728E222DCC; Mon, 30 Apr 2018 19:27:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 728E222DCC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=gregkh@linuxfoundation.org From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lukas Czerner , Theodore Tso , Ilya Dryomov Subject: [PATCH 4.14 05/91] ext4: fix bitmap position validation Date: Mon, 30 Apr 2018 12:23:47 -0700 Message-Id: <20180430184004.492294634@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180430184004.216234025@linuxfoundation.org> References: <20180430184004.216234025@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lukas Czerner commit 22be37acce25d66ecf6403fc8f44df9c5ded2372 upstream. Currently in ext4_valid_block_bitmap() we expect the bitmap to be positioned anywhere between 0 and s_blocksize clusters, but that's wrong because the bitmap can be placed anywhere in the block group. This causes false positives when validating bitmaps on perfectly valid file system layouts. Fix it by checking whether the bitmap is within the group boundary. The problem can be reproduced using the following mkfs -t ext3 -E stride=256 /dev/vdb1 mount /dev/vdb1 /mnt/test cd /mnt/test wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.3.tar.xz tar xf linux-4.16.3.tar.xz This will result in the warnings in the logs EXT4-fs error (device vdb1): ext4_validate_block_bitmap:399: comm tar: bg 84: block 2774529: invalid block bitmap [ Changed slightly for clarity and to not drop a overflow test -- TYT ] Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Reported-by: Ilya Dryomov Fixes: 7dac4a1726a9 ("ext4: add validity checks for bitmap block numbers") Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/ext4/balloc.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c @@ -321,6 +321,7 @@ static ext4_fsblk_t ext4_valid_block_bit struct ext4_sb_info *sbi = EXT4_SB(sb); ext4_grpblk_t offset; ext4_grpblk_t next_zero_bit; + ext4_grpblk_t max_bit = EXT4_CLUSTERS_PER_GROUP(sb); ext4_fsblk_t blk; ext4_fsblk_t group_first_block; @@ -338,7 +339,7 @@ static ext4_fsblk_t ext4_valid_block_bit /* check whether block bitmap block number is set */ blk = ext4_block_bitmap(sb, desc); offset = blk - group_first_block; - if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize || + if (offset < 0 || EXT4_B2C(sbi, offset) >= max_bit || !ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data)) /* bad block bitmap */ return blk; @@ -346,7 +347,7 @@ static ext4_fsblk_t ext4_valid_block_bit /* check whether the inode bitmap block number is set */ blk = ext4_inode_bitmap(sb, desc); offset = blk - group_first_block; - if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize || + if (offset < 0 || EXT4_B2C(sbi, offset) >= max_bit || !ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data)) /* bad block bitmap */ return blk; @@ -354,8 +355,8 @@ static ext4_fsblk_t ext4_valid_block_bit /* check whether the inode table block number is set */ blk = ext4_inode_table(sb, desc); offset = blk - group_first_block; - if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize || - EXT4_B2C(sbi, offset + sbi->s_itb_per_group) >= sb->s_blocksize) + if (offset < 0 || EXT4_B2C(sbi, offset) >= max_bit || + EXT4_B2C(sbi, offset + sbi->s_itb_per_group) >= max_bit) return blk; next_zero_bit = ext4_find_next_zero_bit(bh->b_data, EXT4_B2C(sbi, offset + EXT4_SB(sb)->s_itb_per_group),