From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C49B2C433E0 for ; Wed, 12 Aug 2020 01:35:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8A77A20658 for ; Wed, 12 Aug 2020 01:35:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="CTXO676e" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8A77A20658 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3A9E78D005A; Tue, 11 Aug 2020 21:35:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D8548D0001; Tue, 11 Aug 2020 21:35:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C5808D005A; Tue, 11 Aug 2020 21:35:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) by kanga.kvack.org (Postfix) with ESMTP id 02D1A8D0001 for ; Tue, 11 Aug 2020 21:35:32 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C05848248047 for ; Wed, 12 Aug 2020 01:35:32 +0000 (UTC) X-FDA: 77140199304.13.tent37_16185cc26fe7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 948F218140B60 for ; Wed, 12 Aug 2020 01:35:32 +0000 (UTC) X-HE-Tag: tent37_16185cc26fe7 X-Filterd-Recvd-Size: 3875 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Wed, 12 Aug 2020 01:35:32 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (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 41AB220678; Wed, 12 Aug 2020 01:35:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597196131; bh=DtsMZM/R7Ghz1cP12OeJnMMtEq8agJUF6qSxR0PISec=; h=Date:From:To:Subject:In-Reply-To:From; b=CTXO676enYQ0yM62FU6EDSe7LUtJan+WOlp4RGMjvCzCkzK+joIudFqn1h+UARqGi UfZogeppVe3Tc6NOfWWaoj070YD4cCN1jYDX+HLQcCGbybRfceiukCko49pevI2Amf o9bqhtNnz1jrV0Zo3C8K8b2xdz5iK6bZMKSdIz0c= Date: Tue, 11 Aug 2020 18:35:30 -0700 From: Andrew Morton To: akpm@linux-foundation.org, anenbupt@gmail.com, ebiggers@google.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk Subject: [patch 100/165] fs/minix: reject too-large maximum file size Message-ID: <20200812013530.pczEExpRx%akpm@linux-foundation.org> In-Reply-To: <20200811182949.e12ae9a472e3b5e27e16ad6c@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Queue-Id: 948F218140B60 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Eric Biggers Subject: fs/minix: reject too-large maximum file size If the minix filesystem tries to map a very large logical block number to its on-disk location, block_to_path() can return offsets that are too large, causing out-of-bounds memory accesses when accessing indirect index blocks. This should be prevented by the check against the maximum file size, but this doesn't work because the maximum file size is read directly from the on-disk superblock and isn't validated itself. Fix this by validating the maximum file size at mount time. Link: http://lkml.kernel.org/r/20200628060846.682158-4-ebiggers@kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+c7d9ec7a1a7272dd71b3@syzkaller.appspotmail.com Reported-by: syzbot+3b7b03a0c28948054fb5@syzkaller.appspotmail.com Reported-by: syzbot+6e056ee473568865f3e6@syzkaller.appspotmail.com Signed-off-by: Eric Biggers Cc: Alexander Viro Cc: Qiujun Huang Cc: Signed-off-by: Andrew Morton --- fs/minix/inode.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) --- a/fs/minix/inode.c~fs-minix-reject-too-large-maximum-file-size +++ a/fs/minix/inode.c @@ -150,6 +150,23 @@ static int minix_remount (struct super_b return 0; } +static bool minix_check_superblock(struct minix_sb_info *sbi) +{ + if (sbi->s_imap_blocks == 0 || sbi->s_zmap_blocks == 0) + return false; + + /* + * s_max_size must not exceed the block mapping limitation. This check + * is only needed for V1 filesystems, since V2/V3 support an extra level + * of indirect blocks which places the limit well above U32_MAX. + */ + if (sbi->s_version == MINIX_V1 && + sbi->s_max_size > (7 + 512 + 512*512) * BLOCK_SIZE) + return false; + + return true; +} + static int minix_fill_super(struct super_block *s, void *data, int silent) { struct buffer_head *bh; @@ -228,11 +245,12 @@ static int minix_fill_super(struct super } else goto out_no_fs; + if (!minix_check_superblock(sbi)) + goto out_illegal_sb; + /* * Allocate the buffer map to keep the superblock small. */ - if (sbi->s_imap_blocks == 0 || sbi->s_zmap_blocks == 0) - goto out_illegal_sb; i = (sbi->s_imap_blocks + sbi->s_zmap_blocks) * sizeof(bh); map = kzalloc(i, GFP_KERNEL); if (!map) _