Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp1009028imn; Tue, 26 Jul 2022 15:47:04 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tOC3ka6foBPwNfAY52Vgxoa/iNyQy9EiO+dr0Bff+61cYts9/udfABTIv11zBnzkhq8U7t X-Received: by 2002:a17:906:5d0c:b0:72f:b204:c27b with SMTP id g12-20020a1709065d0c00b0072fb204c27bmr15226248ejt.218.1658875624244; Tue, 26 Jul 2022 15:47:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658875624; cv=none; d=google.com; s=arc-20160816; b=MxDgaMGl22IWYCWWWv2C5L7v9Hssj7K/gntdTn9oT/hxdOmKJaMPqgMWz4jAYwDXPs /uwi51fRX3tYdcM0wo5awej0avYCtxT7XUt9WBBTruzkdFrxP5hsEv9os8ph4jQeBuk5 K0Rud0j3sVxVbiHjHDlUSwDmyp/80POHpeOlfX4ZNvQwI2l6FvjsME1lX7X+U8QLAgJa tm0feOYZjtK/A/6jeB7tz8UlKsOBipD9P3I/rrVnO+ahtQ1w3T5flF2iJ1IAxZDokErh xcRyB+J17OzNW678+mUFTV3PvwZcXV4P0AkHR2lO2ydLmiLx++5KyQ/xpPLh2nbXc0GF aVNw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=EigelYic/mxYtYmvK0d/ECOSCSbvSWY9zQwdwCRE1xU=; b=FZa7M2hb+VB4WsDKaFVqwjt++sVJpPm/DRW0Le6y7yMIW8rdjIOSAVhlStQWC6OZ7T +CEePNHo2y9ULton2t0z+6qZEXQpuowYrVZWavZDCrJQ85bXBtE+6xa8sEFssOT6scOX yiL2XYhEmUcLFDVKRsZit/clYbBfUABQrx9wZnW84HhFQAWJZ+0zY0eoPnEqAKnki6H6 GehyqNHewLxaaVf5jFLBllZi8aWrL0qKrVFaU+i3uVzbifVcewGS7dCSE8VJub8pWhbJ LxXIfXvLMmPQinhXMmlqRVhtzN/JWq0GQmEULoOCv4D/ozTzx+JWROXAk0p1x5tZlkXd 60GA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=UQB5ZRRO; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qk6-20020a1709077f8600b0070397358bcbsi16655239ejc.33.2022.07.26.15.46.12; Tue, 26 Jul 2022 15:47:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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; dkim=pass header.i=@linaro.org header.s=google header.b=UQB5ZRRO; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229532AbiGZWon (ORCPT + 99 others); Tue, 26 Jul 2022 18:44:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231573AbiGZWon (ORCPT ); Tue, 26 Jul 2022 18:44:43 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A32CD32459 for ; Tue, 26 Jul 2022 15:44:41 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id e8-20020a17090a280800b001f2fef7886eso350785pjd.3 for ; Tue, 26 Jul 2022 15:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=EigelYic/mxYtYmvK0d/ECOSCSbvSWY9zQwdwCRE1xU=; b=UQB5ZRRO/QUEJ7UXOy6hfUeP2LGg1iG1G2L6lYRV5CN7MRKqOoRhhJ4LOvk4dTPamc +md4YSbZu+dAdt63YD8hmAv8crfk6YQaADLjxgo+/ld9tgr6+hZ6w/eLdhXZLTDcE+vI ClkDybitc/QF9orOkDDQ4FE77XeMPHs3tS+0otbeBopmtZiSgI7wtixYW/N+tV0VugHQ J2NgbSSfvdA9hY8UkURK6fcJe3veUhbuwVAQVxAWTJHuTxBSsGzjwFssiyA87h8thrSU zPUwHjXaZtrw2AA48hQ2V5ep+pupP4d4X1198rrPhCezPyKz59zOxXTH5gZDeUR/Gq2u rPmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=EigelYic/mxYtYmvK0d/ECOSCSbvSWY9zQwdwCRE1xU=; b=0fbqrBy2tLnuMGBacKmS+YUSnjfvvFxagEH06UtLSSGvaX+ZO+Cni+mdH9MI9heID4 IhueALIch2WvXBecTOAaegsSJUV/0vSmw00eCZZFhbhfBt1wcF8QHtP5pfWiQ6NgyIek uwwNPHZ1NvBy/VbaX+E1ibrKnDWkhUzCrXtUD+cGXyk3gt5hCftnkVwz336ZHrDdkkkY qQJtL0sngtbbUtPFPt8o7RjWrG43c6eJuF0TltirTWgJLDyqOwYRsBNKqR5y2eF9yLJi x2ZLE3ZLPLnIwZZqcAvsLUFwE7EGM3COUn9M6dgAGZol6fwjD+nreXY/GFFVykSxIocM 8y2A== X-Gm-Message-State: AJIora8rmcPhh6+O0bXMIbXnWMNSKY4GuTq8yw68xgqe1h4VL2etsltY nNQsAEWWJVCrD6RnSZucS29LBA== X-Received: by 2002:a17:90a:4e87:b0:1f2:1c52:4082 with SMTP id o7-20020a17090a4e8700b001f21c524082mr1217645pjh.237.1658875481002; Tue, 26 Jul 2022 15:44:41 -0700 (PDT) Received: from desktop.. ([2601:1c0:4c00:ad20:feaa:14ff:fe3a:b225]) by smtp.gmail.com with ESMTPSA id n59-20020a17090a5ac100b001f2b0f8e047sm110408pji.27.2022.07.26.15.44.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Jul 2022 15:44:40 -0700 (PDT) From: Tadeusz Struk To: Theodore Ts'o Cc: Jan Kara , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Tadeusz Struk , syzbot+bd13648a53ed6933ca49@syzkaller.appspotmail.com Subject: [PATCH] ext4: try to flush inline data before calling BUG in writepages Date: Tue, 26 Jul 2022 15:44:28 -0700 Message-Id: <20220726224428.407887-1-tadeusz.struk@linaro.org> X-Mailer: git-send-email 2.37.1 In-Reply-To: <983bb802-d883-18d4-7945-dbfa209c1cc8@linaro.org> References: <983bb802-d883-18d4-7945-dbfa209c1cc8@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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: X-Mailing-List: linux-ext4@vger.kernel.org Fix a syzbot issue, which triggers a BUG in ext4_writepags. The syzbot creates and monuts an ext4 fs image on /dev/loop0. The image is corrupted, which is probably the source of the problems, but the mount operation finishes successfully. Then the repro program creates a file on the mounted fs, and eventually it writes a buff of 22 zero bytes to it as below: memfd_create("syzkaller", 0) = 3 ftruncate(3, 2097152) = 0 pwrite64(3, " \0\0\0\0\2\0\0\31\0\0\0\220\1\0\0\17\0\0\0\0\0\0\0\2\0\0\0\6\0\0\0"..., 102, 1024) = 102 pwrite64(3, "\0\0\0\0\0\0\0\0\0\0\0\0\202\343g$\306\363L\252\204n\322\345'p3x\1\0@", 31, 1248) = 31 pwrite64(3, "\2\0\0\0\3\0\0\0\4\0\0\0\31\0\17\0\3\0\4\0\0\0\0\0\0\0\0\0\17\0.i", 32, 4096) = 32 pwrite64(3, "\177\0\0\0\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 4098, 8192) = 4098 pwrite64(3, "\355A\0\0\20\0\0\0\332\364e_\333\364e_\333\364e_\0\0\0\0\0\0\4\0\200\0\0\0"..., 61, 17408) = 61 openat(AT_FDCWD, "/dev/loop0", O_RDWR) = 4 ioctl(4, LOOP_SET_FD, 3) = 0 mkdir("./file0", 0777) = -1 EEXIST (File exists) mount("/dev/loop0", "./file0", "ext4", 0, ",errors=continue") = 0 openat(AT_FDCWD, "./file0", O_RDONLY|O_DIRECTORY) = 5 ioctl(4, LOOP_CLR_FD) = 0 close(4) = 0 close(3) = 0 chdir("./file0") = 0 creat("./bus", 000) = 3 open("./bus", O_RDWR|O_CREAT|O_NONBLOCK|O_SYNC|O_DIRECT|O_LARGEFILE|O_NOATIME, 000) = 4 openat(AT_FDCWD, "/proc/self/exe", O_RDONLY) = 6 sendfile(4, 6, NULL, 2147483663) = 1638400 open("./bus", O_RDWR|O_CREAT|O_SYNC|O_NOATIME, 000) = 7 write(7, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 22) This triggers a BUG in ext4_writepages(), where it checks if the inode has inline data, just before deleting it: kernel BUG at fs/ext4/inode.c:2721! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 RIP: 0010:ext4_writepages+0x363d/0x3660 RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293 RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180 RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000 RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128 R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001 FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0 Call Trace: do_writepages+0x397/0x640 filemap_fdatawrite_wbc+0x151/0x1b0 file_write_and_wait_range+0x1c9/0x2b0 ext4_sync_file+0x19e/0xa00 vfs_fsync_range+0x17b/0x190 ext4_buffered_write_iter+0x488/0x530 ext4_file_write_iter+0x449/0x1b90 vfs_write+0xbcd/0xf40 ksys_write+0x198/0x2c0 __x64_sys_write+0x7b/0x90 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd This can be prevented by forcing the inline data to be converted and/or flushed beforehand. This patch adds a call to ext4_convert_inline_data() just before the BUG, which fixes the issue. Link: https://syzkaller.appspot.com/bug?id=a1e89d09bbbcbd5c4cb45db230ee28c822953984 Reported-by: syzbot+bd13648a53ed6933ca49@syzkaller.appspotmail.com Signed-off-by: Tadeusz Struk --- fs/ext4/inode.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 84c0eb55071d..de2aa2e79052 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -2717,6 +2717,10 @@ static int ext4_writepages(struct address_space *mapping, ret = PTR_ERR(handle); goto out_writepages; } + + if (ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) + WARN_ON(ext4_convert_inline_data(inode)); + BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)); ext4_destroy_inline_data(handle, inode); -- 2.37.1