Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2352714imm; Thu, 7 Jun 2018 09:13:15 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK3zQr/buw4mxCi+HqOjInkLx9iVRkz9Cy5GnAeOYBGX601JklDwPIEsaON4c2EFVBGdZuj X-Received: by 2002:a17:902:b494:: with SMTP id y20-v6mr2640476plr.136.1528387995556; Thu, 07 Jun 2018 09:13:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528387995; cv=none; d=google.com; s=arc-20160816; b=D8lNsFdOkBsWGe7nlAWIJDxpUxOgYk7NBxpxa+qhIZaIW2HZfz2j9fkCy+vfbscdNh mT9pXNfniG1Up+GCqWnNcmN7PmddunT4zFbD7VZbjr8fkqnUodUvWpjyQw6Ku7JZ81WV QIdQVSYA5xAqaGgZ6d225DD99E2hUYSm5XaECkR3RibyqWKLM2wBxWnhkcYpQg0GMDrp YMFaly7jurX33EOfXXA9J0iUVlHn0UpiIhTYPjG+BnJc6e4IYdUwageRnywAQgGcSsfr Nnzl0PEAF4vmhq77M1m24iveUW65dHBtMt/hZHDyTT8uL64bT1gLBz7+mbTnTepwIysM yMpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=RU/ujxMoMHiVD7wUO5nQlN+QJvEVaJ53NUiLuon8gG8=; b=YR9FglJIKyb48DTHqF7zvKBKE7JeIPu7FQ1Tl138hQtu46WY6F+fx+zTrOTo1BG1qu 87XET7RUhUSVo020KojLlu+otQWzxzvCCiDBtFjvQBeNX2u1OTh+ncRC/EjIZwTVXlde d53erJYm6YyZWNNWQcD+2XeEMrUhU3kyP4oeAjk9btaAQd1B9VZu26A/JBTrMITS2ICs yiYBQ8cpaAXNoaC4Rrxl8RX3HLOEQjijyXjFc6pa2pSc4TMjPFY3d+tC68WsB9xHpxOw cy758o1EibZD257UU/mqnQZ+7mUMypT6b/6v4yl4Il3HetEDY32dOeoQZTPq/N9vjpK+ ITfw== 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 s84-v6si16064557pfg.175.2018.06.07.09.13.01; Thu, 07 Jun 2018 09:13:15 -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 S936094AbeFGQKy (ORCPT + 99 others); Thu, 7 Jun 2018 12:10:54 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:39175 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932973AbeFGOJB (ORCPT ); Thu, 7 Jun 2018 10:09:01 -0400 Received: from [148.252.241.226] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fQvb1-0005Zi-FR; Thu, 07 Jun 2018 15:08:59 +0100 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1fQvax-0002hd-Mg; Thu, 07 Jun 2018 15:08:55 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Theodore Ts'o" , "Ilya Dryomov" , "Lukas Czerner" Date: Thu, 07 Jun 2018 15:05:21 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 020/410] ext4: fix bitmap position validation In-Reply-To: X-SA-Exim-Connect-IP: 148.252.241.226 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.57-rc1 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") Signed-off-by: Ben Hutchings --- fs/ext4/balloc.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c @@ -323,6 +323,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; @@ -340,7 +341,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; @@ -348,7 +349,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; @@ -356,8 +357,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),