Message ID | 20221230110016.476621-2-jun.nie@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp2842192wrt; Fri, 30 Dec 2022 03:20:27 -0800 (PST) X-Google-Smtp-Source: AMrXdXu48f1pYA+LuiHaZR1Si/Tj1P34iW6KDK3bRmWs5Ve1mRxow3ZYTQyeHJlAizzhTsPrCDVg X-Received: by 2002:a17:902:6b89:b0:18f:6cb:1730 with SMTP id p9-20020a1709026b8900b0018f06cb1730mr31753165plk.26.1672399226864; Fri, 30 Dec 2022 03:20:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672399226; cv=none; d=google.com; s=arc-20160816; b=eWB5Xoq8GL+ebvqJ6/8HVSndlA80VGJSfSI5ajqBS7avllG8g41tbyQMz2pKWvg8jk JlxapKauhVASr1oztE90rYXBMJBdtTMA0ZCP15ZuTWupkYQklZlZYSCe2lILxFNqq4B3 q25DtVnY7fgJ8jAv1DtV1radTDgN5iae2d0YGVIboPiagg3NF87js26eD3bJ14hzcEi/ fJkoEd34MDyceYhP4XzzaGwva6Mo4SuhB7d3C5QrSWkJlLBnXHgQMIAUsbys/AXIxsJa eB2uVYIaFSvMkQScTbCaDliirpdzPzTfELq862w2Uf2SGVJN/yrAC4cweau5r+9L5xmq L5vw== 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=ahkStRU6mZ/j+Lj49hs0SrtIZtOi4h+JM4lKoZJx6Y0=; b=K9L4+quAhhRYjcW2irSpjjTcOM4HOnlGUEMlZNC73zzTotjFoN++NFfnz5m2C1FekI WX1MJ4QQnfwJT7p439iONT25rnuwNxjTGgmeiAhF8Cdq6Z5Oyuw/f+sBqeWxCjU2PoBQ 8wU7A2KmMNj3MaOlVOYchEgr2gVXLHVRq8ohs/99xdeb1kzRhBLoa96+zb/3AVfjZdh1 iETlru8guid54tUNTkpzLKFazkM4OwSyDFm4/cXPyEBpPS4whHsFTahyOPhx9QzJLPNR Ci/lHJlSmMlcdka6C7EeK6lFIxoiH3okq+dUdLZK7NdApKfF3zoRW9LB3qBRpWNEFQSl Z11Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=e3HEINbn; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h11-20020a170902f2cb00b0017f77922b11si19597175plc.84.2022.12.30.03.20.14; Fri, 30 Dec 2022 03:20:26 -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; dkim=pass header.i=@linaro.org header.s=google header.b=e3HEINbn; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229924AbiL3LAG (ORCPT <rfc822;cscallsign@gmail.com> + 99 others); Fri, 30 Dec 2022 06:00:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234376AbiL3LAD (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 30 Dec 2022 06:00:03 -0500 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 404D71A819 for <linux-kernel@vger.kernel.org>; Fri, 30 Dec 2022 03:00:02 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id o1-20020a17090a678100b00219cf69e5f0so25477704pjj.2 for <linux-kernel@vger.kernel.org>; Fri, 30 Dec 2022 03:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ahkStRU6mZ/j+Lj49hs0SrtIZtOi4h+JM4lKoZJx6Y0=; b=e3HEINbnqThpfVCwEBmANE9t6wazfU0CqSlTPViHpaoGjovSAYUApwjFm3t8bmC8l6 msnEcLQsf9yJERT6yLriiVMPvG/rqyHdhMf7Oc4EVeTnLUlny2erObvsxbvgWLc94I0I Hfp398jakVZquSf0v2Q9BHn1P6pKwBQHP5I/dLz8yzRL9RQxcpX34Zxq9OvNceDdZeyw SzgJQgzUYuE2KS+7/VcVwbRdxLh6rmG4s8b1YGed1CLJSkOoRtVcy4imn6UJsTICbBWQ /pEPtUxYaFybK7GN6cWXHifeJEDCzReTOMtohU/fvz18qaMAUIZZH5Gnwn+xEAQ/wB/2 eufg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ahkStRU6mZ/j+Lj49hs0SrtIZtOi4h+JM4lKoZJx6Y0=; b=QeC3Z7W+1wmfrhSyvR3yRg3BPQKbjIAQY1/a+Qxtu3rs3PbHjMnUb5/DCnlnZivrZ5 0HkezCnyH/Esduwc5eHzTTLmspj/Lkhty4SSHfpd03edM33BqclZ/fcrAmsWS1VNSTFr /+hdQxe5NcMrw5OFny0vd9qddOrnQtA+FS2vazGhpYmIv4QnNz4Jvr5j6Cgz3JDlwD/F H5dC/Vz3fONrM3EJRqQaVlWgYqDIdfJwM2u6uU+V+lDW7io2vmCxWmtjatEg5hCCXZeI ENWdl8KS/LpA7C7TXp2WJevvCdWI/BACLrOFKRleckMAjU6AAUEEESfH9jWUM701Snmc RqJA== X-Gm-Message-State: AFqh2koXu+spRc48TZ4bJ69wejT7IOV/FSXWsTRHApM2Fa8tayeR0joy Jo7Fs0VMqHEmlSusrWrV7+aRUA== X-Received: by 2002:a17:902:848d:b0:189:5f5c:da1d with SMTP id c13-20020a170902848d00b001895f5cda1dmr31017474plo.18.1672398001764; Fri, 30 Dec 2022 03:00:01 -0800 (PST) Received: from niej-dt-7B47.. (80.251.214.228.16clouds.com. [80.251.214.228]) by smtp.gmail.com with ESMTPSA id n6-20020a170903110600b00186a437f4d7sm14662525plh.147.2022.12.30.02.59.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Dec 2022 03:00:01 -0800 (PST) From: Jun Nie <jun.nie@linaro.org> To: tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org Cc: tudor.ambarus@linaro.org Subject: [PATCH 2/2] ext4: refuse to create ea block when umounted Date: Fri, 30 Dec 2022 19:00:16 +0800 Message-Id: <20221230110016.476621-2-jun.nie@linaro.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221230110016.476621-1-jun.nie@linaro.org> References: <20221230110016.476621-1-jun.nie@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: <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?1753637691193650615?= X-GMAIL-MSGID: =?utf-8?q?1753637691193650615?= |
Series |
[1/2] ext4: optimize ea_inode block expansion
|
|
Commit Message
Jun Nie
Dec. 30, 2022, 11 a.m. UTC
The ea block expansion need to access s_root while it is
already set as NULL when umount is triggered. Refuse this
request to avoid panic.
Reported-by: syzbot+2dacb8f015bf1420155f@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=3613786cb88c93aa1c6a279b1df6a7b201347d08
Signed-off-by: Jun Nie <jun.nie@linaro.org>
---
fs/ext4/xattr.c | 6 ++++++
1 file changed, 6 insertions(+)
Comments
On Fri, Dec 30, 2022 at 07:00:16PM +0800, Jun Nie wrote: > The ea block expansion need to access s_root while it is > already set as NULL when umount is triggered. Refuse this > request to avoid panic. > > Reported-by: syzbot+2dacb8f015bf1420155f@syzkaller.appspotmail.com > Link: https://syzkaller.appspot.com/bug?id=3613786cb88c93aa1c6a279b1df6a7b201347d08 > Signed-off-by: Jun Nie <jun.nie@linaro.org> > --- > fs/ext4/xattr.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c > index 235a517d9c17..ac58494e49b6 100644 > --- a/fs/ext4/xattr.c > +++ b/fs/ext4/xattr.c > @@ -1422,6 +1422,12 @@ static struct inode *ext4_xattr_inode_create(handle_t *handle, > uid_t owner[2] = { i_uid_read(inode), i_gid_read(inode) }; > int err; > > + if (inode->i_sb->s_root == NULL) { > + ext4_error(inode->i_sb, > + "refuse to create EA inode when umounting"); > + return ERR_PTR(-EINVAL); > + } > + Why is an xattr being set during unmount? - Eric
On Fri, Dec 30, 2022 at 12:13:25PM -0800, Eric Biggers wrote: > > diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c > > index 235a517d9c17..ac58494e49b6 100644 > > --- a/fs/ext4/xattr.c > > +++ b/fs/ext4/xattr.c > > @@ -1422,6 +1422,12 @@ static struct inode *ext4_xattr_inode_create(handle_t *handle, > > uid_t owner[2] = { i_uid_read(inode), i_gid_read(inode) }; > > int err; > > > > + if (inode->i_sb->s_root == NULL) { > > + ext4_error(inode->i_sb, > > + "refuse to create EA inode when umounting"); > > + return ERR_PTR(-EINVAL); > > + } This should not be an ext4_error() since this is not a file system corruption issue, but rather a kernel bug. (With the one known example being corrected by the first patch in this patch series. Thanks Jun for working on a patch to things!) This should be replaced by an ext4_warning() followed by a WARN_ON(1), so we can get the stack trace. > Why is an xattr being set during unmount? The scenario was discovered by syzbot; the reproducer did the moral equivalent of this (attached) shell script. It required the combination of lazytime and the debug_want_extra_isize mount options, with a file system with (non-default) ea_inode feature enabled; so it was highly unlikely to happen in real life. For the detailed analysis, see [1] [1] https://lore.kernel.org/all/Y5wGZG05uicAPscI@mit.edu - Ted P.S. Converting this into an xfstests test script to test for a regression of this bug (or a failure to backport this into various stable kernels) is also left as an exercise to the reader. :-) #!/bin/bash -vx # # This reproduces an ext4 bug caused by an unfortunate interaction # between lazytime updates happening when a file system is being # unmounted and expand_extra_isize # # Initially discovered via syzkaller: # https://syzkaller.appspot.com/bug?id=3613786cb88c93aa1c6a279b1df6a7b201347d08 # img=/tmp/foo.img dir=/mnt file=$dir/file0 rm -f $img mke2fs -Fq -t ext4 -I 256 -O ea_inode -b 1024 $img 200k mount $img $dir v=$(dd if=/dev/zero bs=2000 count=1 2>/dev/null | tr '\0' =) touch $file attr -q -s test -V $v $file umount $dir mount -o debug_want_extra_isize=128,lazytime /tmp/foo.img $dir cat $file umount $dir
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index 235a517d9c17..ac58494e49b6 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1422,6 +1422,12 @@ static struct inode *ext4_xattr_inode_create(handle_t *handle, uid_t owner[2] = { i_uid_read(inode), i_gid_read(inode) }; int err; + if (inode->i_sb->s_root == NULL) { + ext4_error(inode->i_sb, + "refuse to create EA inode when umounting"); + return ERR_PTR(-EINVAL); + } + /* * Let the next inode be the goal, so we try and allocate the EA inode * in the same group, or nearby one.