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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 43A13E7718B for ; Mon, 30 Dec 2024 02:53:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ozlabs.org; s=201707; t=1735527204; bh=WDAkKZXgZ5WE2BvxAr2caCwoiXmIrq4mEYt9vI0pzFk=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=DMfZYgv7WJxO7gRF4WXOWXrT+flBUGUKvOvHwFybcUH3EqcL5y6xlBkRDd62PRLXd uQK5bzPnRelEP43qaRJSoNfOgLBknfEzFnSnx3+8lHpXVGcEppBjciq93xEyvAlkn4 dD/TeaCXI7sJcg6HaM/AD5Te7gV1LT30LLq6avU5rQuQ0rRyqNnDlMDSODnmUCRpxx Ngp+ST8RxPxkvN/tbjXRUwMq5W8QFFQWQTIHyUeqxouy/p9/zzVg4ewoykmOvF+F/F tzRSmzhLjDnKzPdm0mp1TyaPAMGwc/z7EZy7Jv/OzS5NjVngmBsc63gKgY+3lLEZiy D7/Fg9ENIqF4A== Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4YM0z80gHjz3020 for ; Mon, 30 Dec 2024 13:53:24 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=139.178.84.217 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1735527201; cv=none; b=UgODM6f3Jm5rCERWcwpxbgYOXhaR81KSjuo4LU4Mw32G205hxp8XIaolJB+Ob0BAVqC/gsqgib50aEGqBzkBlEkpxMTuHyCxOHCSEPdNYwPYuvlHIUeeH1sV3MPMN/EDUQcR3xHJlT37Z2q3ffTrVYZcVuwodzR6leBNZDd4zWadwNEV6gJHRBiPHYbJHJdY4DgVq1RPGDa60rdCuqsSGjc/PEN82xoNsnVvffmNfZG3W7SA1BBdYLcq4ii09nL6Vx+Zaz8o9HfY5+KKAqCMHHTRwyDY14nntgDN3rNStUF/RTTXTclM5WPeS5zKEUsGsvsrzuZn2856sIkM4WFJ/w== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1735527201; c=relaxed/relaxed; bh=WDAkKZXgZ5WE2BvxAr2caCwoiXmIrq4mEYt9vI0pzFk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Xc85inKnemDdeSFNdTciMsgUR2DUQDow5WozVPreYmH5xkOMzzPmid0sOxZhd9InoaH579EUFLnALy7eVWqPo+QnrBRMlRfsib5BFQYfPhKg1td0ZksUT5L9PqB8NftQmHDOJlpgF0kq+TbeXriF7s4Bmkt8B/BiXfF1X4dgqMrKHobktl5wHp4Ml7l6aHMDfCxn4GdzAkvUSLCwhYXXKpLoW+//dAfdbknogVyk31qKJxnojrGa64IlotikYUfOirrrtjcqe4ccLbHeSBquywwODV3WWtVxToZZAIhDqBu0P42DP1X/FQLGa/FG/XW05IBDcK3tBOWxYyhDAUNdiA== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=tdlLUjgL; dkim-atps=neutral; spf=pass (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=xiang@kernel.org; receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org Authentication-Results: lists.ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=tdlLUjgL; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=xiang@kernel.org; receiver=lists.ozlabs.org) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4YM0z44nvNz2xt7 for ; Mon, 30 Dec 2024 13:53:20 +1100 (AEDT) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id DFD235C10BD; Mon, 30 Dec 2024 02:52:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CE25C4CED1; Mon, 30 Dec 2024 02:53:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1735527197; bh=5T9teM4X9U6CZgzJeAePaUsIgwgB+c9qSGbOu6Aqdas=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tdlLUjgLD0d+pYeUHApaM9XfKCRQydFKAGETmR5KTsbUl8yBl/jfXqdb+9T4gO5/6 DHk5eHRi0sSBwb/eUt2UMY4zilp73rHSW/LAHhRBLjdOIcZUPnR/NFgKg4KUMPGoO7 cVH0JSaqTl/S3Q2GvqfnXsOr048iHo096Uo5xxB706BcyZ3b2vkOR3Lx+0v1QEWDHB KZvAauIleTO7vrVWOAkhWqvY/jtqo+3HVdoS9Y3/rW3Bhk2Cs+Bs2PC8B2vsZVS3Ks Wo/jk7Ugo3ifDbOwDCNhpnziFWwWpjfU/G5aqbYZ1CohJBAsZjjEVZmtLyxzr+YNLe QNpOMUIx5bHUg== Date: Mon, 30 Dec 2024 10:53:11 +0800 To: Namjae Jeon , Sungjong Seo , Yuezhang Mo , syzbot Subject: Re: [syzbot] [erofs?] KMSAN: uninit-value in erofs_fc_fill_super Message-ID: Mail-Followup-To: Namjae Jeon , Sungjong Seo , Yuezhang Mo , syzbot , linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com References: <6770fe12.050a0220.226966.00bb.GAE@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6770fe12.050a0220.226966.00bb.GAE@google.com> X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Gao Xiang via Linux-erofs Reply-To: Gao Xiang Cc: syzkaller-bugs@googlegroups.com, linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" Hi exfat maintainers, On Sat, Dec 28, 2024 at 11:45:22PM -0800, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 9b2ffa6148b1 Merge tag 'mtd/fixes-for-6.13-rc5' of git://g.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=112374c4580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=f9048090d7bb0d06 > dashboard link: https://syzkaller.appspot.com/bug?extid=1379ee6b9a14d5dacaf2 > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > Unfortunately, I don't have any reproducer for this issue yet. > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/244f25c1a275/disk-9b2ffa61.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/0d14fc6634fd/vmlinux-9b2ffa61.xz > kernel image: https://storage.googleapis.com/syzbot-assets/cb152a4c0fd2/bzImage-9b2ffa61.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+1379ee6b9a14d5dacaf2@syzkaller.appspotmail.com > > exFAT-fs (loop7): failed to load upcase table (idx : 0x00010000, chksum : 0x1a9973fb, utbl_chksum : 0xe619d30d) > ===================================================== > BUG: KMSAN: uninit-value in erofs_read_superblock fs/erofs/super.c:274 [inline] > BUG: KMSAN: uninit-value in erofs_fc_fill_super+0x66a/0x2520 fs/erofs/super.c:614 > erofs_read_superblock fs/erofs/super.c:274 [inline] > erofs_fc_fill_super+0x66a/0x2520 fs/erofs/super.c:614 > vfs_get_super fs/super.c:1280 [inline] > get_tree_nodev+0x183/0x350 fs/super.c:1299 > erofs_fc_get_tree+0x34d/0x450 fs/erofs/super.c:721 > vfs_get_tree+0xb1/0x5a0 fs/super.c:1814 > do_new_mount+0x71f/0x15e0 fs/namespace.c:3507 > path_mount+0x742/0x1f10 fs/namespace.c:3834 > do_mount fs/namespace.c:3847 [inline] > __do_sys_mount fs/namespace.c:4057 [inline] > __se_sys_mount+0x722/0x810 fs/namespace.c:4034 > __x64_sys_mount+0xe4/0x150 fs/namespace.c:4034 > x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > Uninit was created at: > __alloc_pages_noprof+0x9a7/0xe00 mm/page_alloc.c:4776 > alloc_pages_mpol_noprof+0x299/0x990 mm/mempolicy.c:2269 > alloc_pages_noprof mm/mempolicy.c:2348 [inline] > folio_alloc_noprof+0x1db/0x310 mm/mempolicy.c:2355 > filemap_alloc_folio_noprof+0xa6/0x440 mm/filemap.c:1009 > __filemap_get_folio+0xac4/0x1550 mm/filemap.c:1951 > block_write_begin+0x6e/0x2b0 fs/buffer.c:2221 > exfat_write_begin+0xfb/0x400 fs/exfat/inode.c:434 > exfat_extend_valid_size fs/exfat/file.c:553 [inline] > exfat_file_write_iter+0x771/0x12a0 fs/exfat/file.c:598 > do_iter_readv_writev+0x88a/0xa30 > vfs_writev+0x56a/0x14f0 fs/read_write.c:1050 > do_pwritev fs/read_write.c:1146 [inline] > __do_sys_pwritev2 fs/read_write.c:1204 [inline] > __se_sys_pwritev2+0x262/0x460 fs/read_write.c:1195 > __x64_sys_pwritev2+0x11f/0x1a0 fs/read_write.c:1195 > x64_sys_call+0x368c/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:329 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > Currently, I don't think it's an EROFS issue but since it doesn't have a valid reproducer so I don't have an exact idea. This case is out of EROFS file-backed mount, which seems to read EROFS superblock (erofs_read_superblock -> erofs_read_metabuf -> erofs_bread) via exfat page cache: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/erofs/super.c?h=v6.13-rc5#n274 But it seems exfat returns an unlocked uptodate page without fully initialized data. I'm not sure if it's a post-EOF read for this specific regular inode, but IMHO, at least mmap read allows post-EOF read within the same page, so it'd be better to leave the whole page initialized on the exfat side. I'm not sure if it's related to exfat_extend_valid_size() though. Thanks, Gao Xiang From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 405782594B3 for ; Mon, 30 Dec 2024 02:53:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735527198; cv=none; b=O8G52OssTRL07hK3Yi24a54VSu8nuaZazi1ucw4eXg7wGhrMlz7eGomwPzUgtMfUOzdCKE2FxkApCbkgv1DeFR4nwvysU248vWx+QTmtWC9LKobVhZSmpqrygcArsalHRZ0lLxuszseYb3BmP2VdCxqTQOWzxgmIrSPXg4FB5RU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735527198; c=relaxed/simple; bh=5T9teM4X9U6CZgzJeAePaUsIgwgB+c9qSGbOu6Aqdas=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WtGG3nIfvryGMg4FkfOXb1gJxqznOJUwTRHGqXh2yVecDsePfwqMZV6UH8vSlA75I3FMZs5fvlFzfStU64uys/ewzJbUgvRJo9KAg7M1JcPZPR3ebPHibXhRDxFfNwL5axP9sKK8AajCwd5pIVFeIv8H9cnnae3vkmfEkcvMGng= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tdlLUjgL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tdlLUjgL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CE25C4CED1; Mon, 30 Dec 2024 02:53:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1735527197; bh=5T9teM4X9U6CZgzJeAePaUsIgwgB+c9qSGbOu6Aqdas=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tdlLUjgLD0d+pYeUHApaM9XfKCRQydFKAGETmR5KTsbUl8yBl/jfXqdb+9T4gO5/6 DHk5eHRi0sSBwb/eUt2UMY4zilp73rHSW/LAHhRBLjdOIcZUPnR/NFgKg4KUMPGoO7 cVH0JSaqTl/S3Q2GvqfnXsOr048iHo096Uo5xxB706BcyZ3b2vkOR3Lx+0v1QEWDHB KZvAauIleTO7vrVWOAkhWqvY/jtqo+3HVdoS9Y3/rW3Bhk2Cs+Bs2PC8B2vsZVS3Ks Wo/jk7Ugo3ifDbOwDCNhpnziFWwWpjfU/G5aqbYZ1CohJBAsZjjEVZmtLyxzr+YNLe QNpOMUIx5bHUg== Date: Mon, 30 Dec 2024 10:53:11 +0800 From: Gao Xiang To: Namjae Jeon , Sungjong Seo , Yuezhang Mo , syzbot Cc: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [erofs?] KMSAN: uninit-value in erofs_fc_fill_super Message-ID: Mail-Followup-To: Namjae Jeon , Sungjong Seo , Yuezhang Mo , syzbot , linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com References: <6770fe12.050a0220.226966.00bb.GAE@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6770fe12.050a0220.226966.00bb.GAE@google.com> Hi exfat maintainers, On Sat, Dec 28, 2024 at 11:45:22PM -0800, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 9b2ffa6148b1 Merge tag 'mtd/fixes-for-6.13-rc5' of git://g.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=112374c4580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=f9048090d7bb0d06 > dashboard link: https://syzkaller.appspot.com/bug?extid=1379ee6b9a14d5dacaf2 > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > Unfortunately, I don't have any reproducer for this issue yet. > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/244f25c1a275/disk-9b2ffa61.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/0d14fc6634fd/vmlinux-9b2ffa61.xz > kernel image: https://storage.googleapis.com/syzbot-assets/cb152a4c0fd2/bzImage-9b2ffa61.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+1379ee6b9a14d5dacaf2@syzkaller.appspotmail.com > > exFAT-fs (loop7): failed to load upcase table (idx : 0x00010000, chksum : 0x1a9973fb, utbl_chksum : 0xe619d30d) > ===================================================== > BUG: KMSAN: uninit-value in erofs_read_superblock fs/erofs/super.c:274 [inline] > BUG: KMSAN: uninit-value in erofs_fc_fill_super+0x66a/0x2520 fs/erofs/super.c:614 > erofs_read_superblock fs/erofs/super.c:274 [inline] > erofs_fc_fill_super+0x66a/0x2520 fs/erofs/super.c:614 > vfs_get_super fs/super.c:1280 [inline] > get_tree_nodev+0x183/0x350 fs/super.c:1299 > erofs_fc_get_tree+0x34d/0x450 fs/erofs/super.c:721 > vfs_get_tree+0xb1/0x5a0 fs/super.c:1814 > do_new_mount+0x71f/0x15e0 fs/namespace.c:3507 > path_mount+0x742/0x1f10 fs/namespace.c:3834 > do_mount fs/namespace.c:3847 [inline] > __do_sys_mount fs/namespace.c:4057 [inline] > __se_sys_mount+0x722/0x810 fs/namespace.c:4034 > __x64_sys_mount+0xe4/0x150 fs/namespace.c:4034 > x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > Uninit was created at: > __alloc_pages_noprof+0x9a7/0xe00 mm/page_alloc.c:4776 > alloc_pages_mpol_noprof+0x299/0x990 mm/mempolicy.c:2269 > alloc_pages_noprof mm/mempolicy.c:2348 [inline] > folio_alloc_noprof+0x1db/0x310 mm/mempolicy.c:2355 > filemap_alloc_folio_noprof+0xa6/0x440 mm/filemap.c:1009 > __filemap_get_folio+0xac4/0x1550 mm/filemap.c:1951 > block_write_begin+0x6e/0x2b0 fs/buffer.c:2221 > exfat_write_begin+0xfb/0x400 fs/exfat/inode.c:434 > exfat_extend_valid_size fs/exfat/file.c:553 [inline] > exfat_file_write_iter+0x771/0x12a0 fs/exfat/file.c:598 > do_iter_readv_writev+0x88a/0xa30 > vfs_writev+0x56a/0x14f0 fs/read_write.c:1050 > do_pwritev fs/read_write.c:1146 [inline] > __do_sys_pwritev2 fs/read_write.c:1204 [inline] > __se_sys_pwritev2+0x262/0x460 fs/read_write.c:1195 > __x64_sys_pwritev2+0x11f/0x1a0 fs/read_write.c:1195 > x64_sys_call+0x368c/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:329 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > Currently, I don't think it's an EROFS issue but since it doesn't have a valid reproducer so I don't have an exact idea. This case is out of EROFS file-backed mount, which seems to read EROFS superblock (erofs_read_superblock -> erofs_read_metabuf -> erofs_bread) via exfat page cache: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/erofs/super.c?h=v6.13-rc5#n274 But it seems exfat returns an unlocked uptodate page without fully initialized data. I'm not sure if it's a post-EOF read for this specific regular inode, but IMHO, at least mmap read allows post-EOF read within the same page, so it'd be better to leave the whole page initialized on the exfat side. I'm not sure if it's related to exfat_extend_valid_size() though. Thanks, Gao Xiang