Message ID | 20221208023233.1231330-2-yebin@huaweicloud.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp516518wrr; Wed, 7 Dec 2022 18:14:32 -0800 (PST) X-Google-Smtp-Source: AA0mqf7xLEqNbBzc990nU8MTO76NIQWTBeZdKv07AKmimhMpD9Lp/NYv4KTPSk+9B0GITlY7gb77 X-Received: by 2002:a17:902:c1cd:b0:189:6b31:dc53 with SMTP id c13-20020a170902c1cd00b001896b31dc53mr60711959plc.58.1670465671734; Wed, 07 Dec 2022 18:14:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670465671; cv=none; d=google.com; s=arc-20160816; b=wX9rJblC6zYwxjSMhDypmOJez67Vp7KneClm4NvTi9F2Yf9MuxYBxR346nRqy16NdP bYHBom14RjWPmPkKgVF19tagLSfs8dR/DT+DMiFCJWOcibnMw9BAKAFwh/WYslA1J9WW G/GIAzVtU9VBFxWggAfvFdqgXf9qikFHjqx/SE5PEeXWzwVmj+4qEQh6PU7wTCQQTbZn aVVIFhz+gvIfiTerVCL+V3JWA10Vfs/thtkGb7c0aK5ppbi/nyi36dh569Mwf1XaIcz7 N+y6FDWGebOyk32ixGpDGaMh9XdKXNYmJE7Pc19sevrQCNmjxjM7RbkFV6XDfHy+qgZf 55+w== 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; bh=UHOHASLecbS7Yb7BfyG8eiiHHx7AEpC2ocH7RbM1MDA=; b=VMyl9TdwfFeAClqNaj9zvVD08G7rF4J6b/Sic3DnPljxosRoqLm5zgtJXg70cqxnyh H1pN41II5r5DHZLucq3v0rIKDfLGDDZ7E1EH9clLaJnjq3dinF9f4wKR8MEAGro2yESk nNK6J49N+U64K5vSHP/LyRIJY/c8aUMyPitxsbI4XqxWBg3rIkchSOZ90MdhZn+D2HLm eamz5Wo4GpLBdyX+BA8asnxIKnyqH3kW3jn51V7NUbRqyE8vdlUl0alRPT6ckEGIg8bd QQw4BIDingmLbKh0RXGIYBY8Ivh6oIl204/iAJtsCL5ZQ1QMUueEe+vo74TGH3qCIuQO +8GQ== 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ij27-20020a170902ab5b00b0018990b83e0esi21160480plb.422.2022.12.07.18.14.18; Wed, 07 Dec 2022 18:14:31 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229750AbiLHCLq (ORCPT <rfc822;foxyelen666@gmail.com> + 99 others); Wed, 7 Dec 2022 21:11:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229689AbiLHCLp (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 7 Dec 2022 21:11:45 -0500 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BABD792A3F; Wed, 7 Dec 2022 18:11:43 -0800 (PST) Received: from mail02.huawei.com (unknown [172.30.67.153]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4NSHhV0pM2z4f3m6k; Thu, 8 Dec 2022 10:11:38 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.127.227]) by APP4 (Coremail) with SMTP id gCh0CgB3m9jbR5Fjj5BiBw--.22193S5; Thu, 08 Dec 2022 10:11:41 +0800 (CST) From: Ye Bin <yebin@huaweicloud.com> To: tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org Cc: linux-kernel@vger.kernel.org, jack@suse.cz, Ye Bin <yebin10@huawei.com>, syzbot+4d99a966fd74bdeeec36@syzkaller.appspotmail.com Subject: [PATCH v3 1/4] ext4: fix WARNING in ext4_expand_extra_isize_ea Date: Thu, 8 Dec 2022 10:32:30 +0800 Message-Id: <20221208023233.1231330-2-yebin@huaweicloud.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20221208023233.1231330-1-yebin@huaweicloud.com> References: <20221208023233.1231330-1-yebin@huaweicloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: gCh0CgB3m9jbR5Fjj5BiBw--.22193S5 X-Coremail-Antispam: 1UD129KBjvJXoWxGrW3JFy5KrWkJr4rZr4kXrb_yoWrtFW5pw 43A347Cr48XF9rCF4xAr1jqw1DWwn3CF4UAryxWrn7ZFy3Xw1xKa95Kr4SqFyxtrW8Jry2 qFn8J34rKw15GaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvGb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI8067AKxVWUGw A2048vs2IY020Ec7CjxVAFwI0_JFI_Gr1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxS w2x7M28EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxV W8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMc Ij6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_ Jr0_Gr1lF7xvr2IYc2Ij64vIr41l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr 0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY 17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcV C0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY 6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa 73UjIFyTuYvjxUzl1vUUUUU X-CM-SenderInfo: p1hex046kxt4xhlfz01xgou0bp/ X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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?1751610212490425318?= X-GMAIL-MSGID: =?utf-8?q?1751610212490425318?= |
Series |
Fix two issue about ext4 extended attribute
|
|
Commit Message
Ye Bin
Dec. 8, 2022, 2:32 a.m. UTC
From: Ye Bin <yebin10@huawei.com> Syzbot found the following issue: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 3631 at mm/page_alloc.c:5534 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5534 Modules linked in: CPU: 1 PID: 3631 Comm: syz-executor261 Not tainted 6.1.0-rc6-syzkaller-00308-g644e9524388a #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5534 RSP: 0018:ffffc90003ccf080 EFLAGS: 00010246 RAX: ffffc90003ccf0e0 RBX: 000000000000000c RCX: 0000000000000000 RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003ccf108 RBP: ffffc90003ccf198 R08: dffffc0000000000 R09: ffffc90003ccf0e0 R10: fffff52000799e21 R11: 1ffff92000799e1c R12: 0000000000040c40 R13: 1ffff92000799e18 R14: dffffc0000000000 R15: 1ffff92000799e14 FS: 0000555555c10300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc36f70000 CR3: 00000000744ad000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __alloc_pages_node include/linux/gfp.h:223 [inline] alloc_pages_node include/linux/gfp.h:246 [inline] __kmalloc_large_node+0x8a/0x1a0 mm/slab_common.c:1096 __do_kmalloc_node mm/slab_common.c:943 [inline] __kmalloc+0xfe/0x1a0 mm/slab_common.c:968 kmalloc include/linux/slab.h:558 [inline] ext4_xattr_move_to_block fs/ext4/xattr.c:2558 [inline] ext4_xattr_make_inode_space fs/ext4/xattr.c:2673 [inline] ext4_expand_extra_isize_ea+0xe3f/0x1cd0 fs/ext4/xattr.c:2765 __ext4_expand_extra_isize+0x2b8/0x3f0 fs/ext4/inode.c:5857 ext4_try_to_expand_extra_isize fs/ext4/inode.c:5900 [inline] __ext4_mark_inode_dirty+0x51a/0x670 fs/ext4/inode.c:5978 ext4_inline_data_truncate+0x548/0xd00 fs/ext4/inline.c:2021 ext4_truncate+0x341/0xeb0 fs/ext4/inode.c:4221 ext4_process_orphan+0x1aa/0x2d0 fs/ext4/orphan.c:339 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474 __ext4_fill_super fs/ext4/super.c:5515 [inline] ext4_fill_super+0x80ed/0x8610 fs/ext4/super.c:5643 get_tree_bdev+0x400/0x620 fs/super.c:1324 vfs_get_tree+0x88/0x270 fs/super.c:1531 do_new_mount+0x289/0xad0 fs/namespace.c:3040 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Reason is allocate 16M memory by kmalloc, but MAX_ORDER is 11, kmalloc can allocate maximum size memory is 4M. XATTR_SIZE_MAX is currently 64K, but EXT4_XATTR_SIZE_MAX is 16M, so 'ext4_xattr_check_entries()' regards this length as legal. Then trigger warning in 'ext4_xattr_move_to_block()'. To solve above issue, change EXT4_XATTR_SIZE_MAX from 16M to 64K. As VFS limit extended attribute maximum size to 64K. So we can assume that there will be no extended attribute with a length greater than 64K. Reported-by: syzbot+4d99a966fd74bdeeec36@syzkaller.appspotmail.com Fixes: 54dd0e0a1b25 ("ext4: add extra checks to ext4_xattr_block_get()") Signed-off-by: Ye Bin <yebin10@huawei.com> --- fs/ext4/xattr.h | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)
Comments
In general, please don't use commit summaries like: ext4: fix WARNING in ext4_expand_extra_isize_ea The commit summary should be a summary of what the change *does*. A description of *why* the change is needed is properly placed in the body of the description. So something like "ext4: clamp EXT4_XATTR_SIZE_MAX to XATTR_SIZE_MAX" would be a better one-line commit summary. That being said, I've decided to not apply this patch. A 16 MB extended attribute size is not _that_ insane, although admittedly it's quite bit larger than any other file system or OS supports (unless you include Solaris and NTFS's alternate data forks as "extended attributes"). I personally don't think the mm/page_alloc warning is that big of a deal (even if it does cause a Syzbot report), and if you really do care about suppressing the warning, using the kvmalloc() instead of kmalloc() will do that --- and it does make ext4 friendly in the case of where we are storing, say, a 30KB Windows ACL as an extended attribute, since it avoided needing to make a order 3 page allocation. (Which again, as far as I'm concerned, is more important than the suppressing the page_alloc warning.) We may ultimately decide to clamp EXT4_XATTR_SIZE_MAX to XATTR_SIZE_MAX, but one could imagine some system attribute that in the future might want to be larger than 32k, that wouldn't be accessed via the standard xattr API. That seems unlikely, but I want to keep our options open. Cheers, - Ted
diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h index 824faf0b15a8..c71e582b1007 100644 --- a/fs/ext4/xattr.h +++ b/fs/ext4/xattr.h @@ -71,15 +71,10 @@ struct ext4_xattr_entry { #define IFIRST(hdr) ((struct ext4_xattr_entry *)((hdr)+1)) /* - * XATTR_SIZE_MAX is currently 64k, but for the purposes of checking - * for file system consistency errors, we use a somewhat bigger value. - * This allows XATTR_SIZE_MAX to grow in the future, but by using this - * instead of INT_MAX for certain consistency checks, we don't need to - * worry about arithmetic overflows. (Actually XATTR_SIZE_MAX is - * defined in include/uapi/linux/limits.h, so changing it is going - * not going to be trivial....) + * Use XATTR_SIZE_MAX to checking for file system consistency errors. Extended + * attribute length exceed XATTR_SIZE_MAX is illegal. */ -#define EXT4_XATTR_SIZE_MAX (1 << 24) +#define EXT4_XATTR_SIZE_MAX XATTR_SIZE_MAX /* * The minimum size of EA value when you start storing it in an external inode