Message ID | 20230308032643.641113-1-chengzhihao1@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp110739wrd; Tue, 7 Mar 2023 19:23:27 -0800 (PST) X-Google-Smtp-Source: AK7set+9fCN2Tey0JLjsvVozckfHbRDRSxkSROka2+V9fCmcEXAVtcRL8+dtZVKXx+4nkppWmEey X-Received: by 2002:a17:90a:e7ca:b0:234:f77:d6d2 with SMTP id kb10-20020a17090ae7ca00b002340f77d6d2mr17570633pjb.45.1678245807625; Tue, 07 Mar 2023 19:23:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678245807; cv=none; d=google.com; s=arc-20160816; b=N7K/DS4TpsJbLCxkT9oyl39Sdxg280ERAdlBp2a8iEO5YlWj/HTupSNxqOPGwHTphu rekpxbjm03JE+ncgFlndMfM8Q8zd59ban8XqI7FIGXiMBpAEa71q94QyD6pCs6/wXeaK opiGCEYHVv0EcaiGXnIjlWrV4pfwxBPCD9elCOhfmgHULmXaUDz5z/rd1qJa0MUeAtCm 9k5hLOmKsWVu83nuRBDA58VaQWeYLp1Fbux2c4QMGP12IhY4gbdixdgu5wPT+LjBgHM2 PWJD7imXFZoJxkGMK7yOnf9XahbTTsQelSgnAIZf//W22KRiJ+o6dHyVGmAcZNYvRBLv 9+uQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=/332qVno6m5XWihs82nB5pDn1mx3j10R1KBgSBvLWCg=; b=ZdsLhNn3Qi/W2E1DgZNR5A/BBt1q+D9gowtDOE3JBMLTfJ8Xqa+7XuocYpxNc9RRom e99+a8VMk+K1G0VywkDiHCiOSITKIKKuBFF2GcIwPEGAUfE0mcSGKjWO5aU8C+NUrecE cEdjhVlZYl/69aji+ZoCT0KgFDQpAv6NwevRY7o28oez8BDSf3fwIgaftD28LKvN2d17 dEVkslj+YNogN2N7WTLS5XrxmUWor2b/ebsxQ2GgybRyoG+kYWOAETd/M86YBfIipYmB CaozufAl1/WldDMcIY9WXKhuUdNKmgr7Kn0eREu/365Wcy7jQFFf1b1dkng5zc0lBy/+ n9ZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lx10-20020a17090b4b0a00b00205da45d8a5si18530928pjb.124.2023.03.07.19.23.11; Tue, 07 Mar 2023 19:23:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229755AbjCHDDk (ORCPT <rfc822;toshivichauhan@gmail.com> + 99 others); Tue, 7 Mar 2023 22:03:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229483AbjCHDDi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Mar 2023 22:03:38 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 513C5584B4; Tue, 7 Mar 2023 19:03:37 -0800 (PST) Received: from kwepemm600013.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4PWcWg17kyznWd1; Wed, 8 Mar 2023 11:00:47 +0800 (CST) Received: from huawei.com (10.175.127.227) by kwepemm600013.china.huawei.com (7.193.23.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Wed, 8 Mar 2023 11:03:34 +0800 From: Zhihao Cheng <chengzhihao1@huawei.com> To: <jack@suse.com>, <tytso@mit.edu>, <adilger.kernel@dilger.ca> CC: <linux-ext4@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <chengzhihao1@huawei.com>, <yi.zhang@huawei.com> Subject: [PATCH] ext4: Fix WANRON caused by unconsistent boot loader inode's i_size and i_disksize Date: Wed, 8 Mar 2023 11:26:43 +0800 Message-ID: <20230308032643.641113-1-chengzhihao1@huawei.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600013.china.huawei.com (7.193.23.68) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759768275653680528?= X-GMAIL-MSGID: =?utf-8?q?1759768275653680528?= |
Series |
ext4: Fix WANRON caused by unconsistent boot loader inode's i_size and i_disksize
|
|
Commit Message
Zhihao Cheng
March 8, 2023, 3:26 a.m. UTC
Using corrupted ext4 image(non-zero i_size for boot loader inode) could
trigger WARNON 'i_size_read(inode) < EXT4_I(inode)->i_disksize' in
ext4_handle_inode_extension():
WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319
CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa
RIP: 0010:ext4_file_write_iter+0xbc7/0xd10
Call Trace:
vfs_write+0x3b1/0x5c0
ksys_write+0x77/0x160
__x64_sys_write+0x22/0x30
do_syscall_64+0x39/0x80
Reproducer (See Link):
1. mount corrupted ext4 image with non-zero i_size for boot loader inode
2. ioctl(fd, EXT4_IOC_SWAP_BOOT)
3. write(fd) // O_DIRECT
Fix it by setting i_disksize while first loading boot loader inode.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159
Cc: <stable@kernel.org>
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
---
fs/ext4/ioctl.c | 1 +
1 file changed, 1 insertion(+)
Comments
On Wed, Mar 08, 2023 at 11:26:43AM +0800, Zhihao Cheng wrote: > Using corrupted ext4 image(non-zero i_size for boot loader inode) could > trigger WARNON 'i_size_read(inode) < EXT4_I(inode)->i_disksize' in > ext4_handle_inode_extension(): > > WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 > CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa > RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 > Call Trace: > vfs_write+0x3b1/0x5c0 > ksys_write+0x77/0x160 > __x64_sys_write+0x22/0x30 > do_syscall_64+0x39/0x80 > > Reproducer (See Link): > 1. mount corrupted ext4 image with non-zero i_size for boot loader inode > 2. ioctl(fd, EXT4_IOC_SWAP_BOOT) > 3. write(fd) // O_DIRECT > > Fix it by setting i_disksize while first loading boot loader inode. Thanks for reporting the bug, but this is not the correct fix. We need to swap i_disksize when we swap i_size in swap_inode_data(). Otherwise, if we fail later in the swap_inode_boot_loader() function, the change to i_datasize won't get undone, which will lead to further problems. The correct fix is here: https://lore.kernel.org/all/20230308041252.GC860405@mit.edu/ - Ted P.S. Chrome refused to download the b.c attachment, claiming it was "dangerous". Perhaps it was because of the commands involving system(3) which among other things, uses dd to overwrite /dev/sda with the image file. It's best if the reproducer program doesn't doesn't make assumption about whether it's safe to randomly dd files to /dev/sda. Of course, I'm a paranoid s.o.b. so I'm not about to download, compile and blindly run a random program that I get from the 'net. :-) But it's actually not all that convenient. So I just deleted all of the system(3) calls from your b.c program, and then used a simple shell script: cp /vtmp/disk /vtmp/foo.img mount -o loop /vtmp/foo.img /mnt cd /mnt /vtmp/b ... where /vtmp in the guest VM is automatically setup if you are using kvm-xfstests[1] to be a 9p file system passthrough of /tmp/kvm-xfstests-$USER on the host. [1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md
Actually, after looking more closely at swap_boot_loader_inode(), your patch is better one. I've dropped mine and applied yours, with commit message clarified a bit: ext4: zero i_disksize when initializing the bootloader inode If the boot loader inode has never been used before, the EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the i_size to 0. However, if the "never before used" boot loader has a non-zero i_size, then i_disksize will be non-zero, and the inconsistency between i_size and i_disksize can trigger a kernel warning: WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 Call Trace: vfs_write+0x3b1/0x5c0 ksys_write+0x77/0x160 __x64_sys_write+0x22/0x30 do_syscall_64+0x39/0x80 Reproducer: 1. create corrupted image and mount it: mke2fs -t ext4 /tmp/foo.img 200 debugfs -wR "sif <5> size 25700" /tmp/foo.img mount -t ext4 /tmp/foo.img /mnt cd /mnt echo 123 > file 2. Run the reproducer program: posix_memalign(&buf, 1024, 1024) fd = open("file", O_RDWR | O_DIRECT); ioctl(fd, EXT4_IOC_SWAP_BOOT); write(fd, buf, 1024); Fix this by setting i_disksize as well as i_size to zero when initiaizing the boot loader inode. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159 Cc: stable@kernel.org Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c index 12435d61f09e..f9a430152063 100644 --- a/fs/ext4/ioctl.c +++ b/fs/ext4/ioctl.c @@ -431,6 +431,7 @@ static long swap_inode_boot_loader(struct super_block *sb, ei_bl->i_flags = 0; inode_set_iversion(inode_bl, 1); i_size_write(inode_bl, 0); + EXT4_I(inode_bl)->i_disksize = inode_bl->i_size; inode_bl->i_mode = S_IFREG; if (ext4_has_feature_extents(sb)) { ext4_set_inode_flag(inode_bl, EXT4_INODE_EXTENTS);