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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BCB7C4167B for ; Tue, 29 Nov 2022 15:55:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F36A6B0072; Tue, 29 Nov 2022 10:55:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A4A76B0073; Tue, 29 Nov 2022 10:55:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86BFB6B0074; Tue, 29 Nov 2022 10:55:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 79CFF6B0072 for ; Tue, 29 Nov 2022 10:55:16 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3D4151201BD for ; Tue, 29 Nov 2022 15:55:16 +0000 (UTC) X-FDA: 80186929032.25.19FE672 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf13.hostedemail.com (Postfix) with ESMTP id 9C3E22000C for ; Tue, 29 Nov 2022 15:55:15 +0000 (UTC) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 2ATFsq3G012855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Nov 2022 10:54:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1669737296; bh=zy1UIZPqhoCDwUnrkLYvCQpT85PKbbZrepuvTkbgSAM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=UcgtUtu12f3XiwepHFKSOTDqnQuVYIPW/YMZdXumAsUGQ7dHH/6CPJ4Ht+zVd11aA kTeAG2t03CqDQ8ZeNn07kPbazdlpNiM/sMxmenLdCGs4YXFpfxdI9baCrLU/EL0cV5 UV5fci8LtA6xQjeA17cv4NkLrLt2GQnjHur5+HFIw5RgIRw9txsIY3gSZPMSk0S+Ln 2JY2fyOxsoiXfhi60JiAJJofTgb5LIiSB3fz6j+Cax9q0S2kygCyGGhvDG2CAXAOgp qIDwG1NBUzrSNahl5Zvtba3qL1ODsxbK5P40kiPLCCDcmjWYYqTQuJKN2vxvH41l3L Gdr8Ji7ttkzFw== Received: by cwcc.thunk.org (Postfix, from userid 15806) id EEC3C15C00E4; Tue, 29 Nov 2022 10:54:51 -0500 (EST) Date: Tue, 29 Nov 2022 10:54:51 -0500 From: "Theodore Ts'o" To: Al Viro Cc: syzbot , akpm@linux-foundation.org, dan.j.williams@intel.com, hch@lst.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, willy@infradead.org Subject: Re: [syzbot] WARNING in iov_iter_revert (3) Message-ID: References: <000000000000519d0205ee4ba094@google.com> <000000000000f5ecad05ee8fccf0@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b=UcgtUtu1; spf=pass (imf13.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669737315; a=rsa-sha256; cv=none; b=Y724S3BuBtMbVTNRDGUcuE53IGCeaQ96dGSuyJM6Lbi7vOIJj3cR4rUrfkxqkjrJoz/PKf PHPzAtkdYGlAAIrPQbjvN8lZwjpRk16PUNKPW3rL1YZNao33s7TkR7GieGhzNWMsEeUwWX xnQJeCGj/k+CfirAdOBDA0wPCgEMRg0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669737315; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zy1UIZPqhoCDwUnrkLYvCQpT85PKbbZrepuvTkbgSAM=; b=Qv0RLr5U8MU+KvkxUbDkLNVMg+sL1+7EN6ioBPpuJIQICl33xzTUpniRKI9t7PKK/8NRZk p0xWoY02/cfVAJ/PZlQ3B8Ay5UL1PlND/9E32WAk+rPooQcLqQUb9/ZrBwW7X9iQUB2iXE GzDKslpIBvha7FSrgDv0qxvByZI3G4s= X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9C3E22000C Authentication-Results: imf13.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b=UcgtUtu1; spf=pass (imf13.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu X-Stat-Signature: 7czh3zcmj5t5xp1gpgkome7s87hszszi X-HE-Tag: 1669737315-453061 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 29, 2022 at 04:04:35AM +0000, Al Viro wrote: > On Mon, Nov 28, 2022 at 02:57:49PM -0800, syzbot wrote: > > syzbot has found a reproducer for the following issue on: > > [snip] > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17219fbb880000 > > "syz_mount_image$ntfs3(" followed by arseloads of garbage. And the thing > conspiciously missing? Why, any ntfs3 maintainers in Cc... Or lists, > for that matter... > > > generic_file_read_iter+0x3d4/0x540 mm/filemap.c:2804 > > do_iter_read+0x6e3/0xc10 fs/read_write.c:796 > > vfs_readv fs/read_write.c:916 [inline] > > do_preadv+0x1f4/0x330 fs/read_write.c:1008 > > 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 > > At a guess - something's screwed in ntfs3 ->direct_IO() (return value, most > likely). And something's screwed in syzbot. If you are fuzzing some > filesystem, YOU REALLY OUGHT TO CC THE MAINTAINERS OF THAT FILESYSTEM. > Even if nothing in the stack trace happens to be in that fs. The scheme which syzbot appears to use involves looking at the symbol in EIP from the stack trace to determine who to CC. This... mostly works, but occasionally results in hilarity. For example, there was the time when the fuzzing program fed some other file system (f2fs, as I recall) several hundred invalid file systems, and then for some reason it fed ext4 an invalid file system, and ext4 tripped on an invalid pointer dereference. Of course, just feeding ext4 the invalid file system had no issues, and a human being might have intuited that maybe the several hundred invalid f2fs file systems triggered some kind of memory corruption which ext4 then tripped across ---- but since the EIP was in the ext4 file system, the ext4 maintainers got cc'ed, and if you look in the dashboard, it just shows an ext4 symbol, so it's unlikely the f2fs developers would ever have discovered it on their own. (I did cc it to them, but they weren't able to get to it immediately, and it'll be hard to find it again, since we don't have a bug tracking system and there's no way to set some kind of "subsystem really at fault" state in the Syzkaller dashboard.) > Folks, it's that simple - "our bot needs to remember that fuzzing $FS > automatically puts maintainers of $FS into the set of people we need to Cc" > vs. "maintainers of each filesystem need to dig into every syzbot posting > on fsdevel (and follow links, no less) to check if their fs might be > involved". If you can't be bothered to take care of the former, why > would you expect $BIGNUM people to bother with the latter, again and > again and again? The strength and weakness of syzkaller is that it will combine fuzzing with, say, setting up and tearing down a gazllion wireguard tunnels, or some other random set of system calls. Sometimes that finds a real bug. Other times, for some strange reason, the syzkaller minimizer can't figure out that the extraneous noise in setting up and tearing down the network connections is pointless noise, except that on the specific hardware/VM used by syzkaller, it helps make it easier to trigger a timing-related bug --- but $DEITY help you if you try to reproduce on anything other than the specific VM used by the syzkaller bug. And then, of course, there are cases where the reproducer is only doing one thing, such as say messing with ntfs3, and the syzbot *should* be able to figure out a better set of maintainers to notify --- but then, given that the syzbot subjust line/summary is something generic, such as iov_iter_XXX, and there's no way to set up an affected subsystem state in the dashboard, good luck having anyone else find it in the syzkaller dashboard later on. > Fix your bot, already. It's not the first time this had been brought > to your attention and the problem is still there. I've brought this to the Syzkaller team's attention multiple times. Unfortunately, it's not exactly a trivial problem to solve, and other things have been considered higher priority. (Hint to the Syzkaller team; if you can prioritize and share a roadmap with upstream developer vis-a-vis upstream concerns, it might make some upstream developers a bit more receptive to patches designed to make life easier for syzkaller to find EVEN MORE FILESYSTEM FUZZING BUGS, such as [1]. Otherwise, it is perhaps understandable why some might consider this more of a threat rather than a benefit... Note: [1] doesn't make a difference for ext4 either way, since metadata checksums is a file system feature that can be enabled or disabled at mkfs time; this patch series is about finding more file system bugs for file systems which don't make disabling checksum to be an option, such as XFS.) [1] https://lore.kernel.org/all/20221014084837.1787196-1-hrkanabar@gmail.com/