From nobody Tue Feb 14 23:27:46 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PGcnk5wYSz3qPWD for ; Tue, 14 Feb 2023 23:27:54 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGcnk3F7Kz4Pyp for ; Tue, 14 Feb 2023 23:27:54 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Authentication-Results: mx1.freebsd.org; none Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 31ENRkRC043412 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Feb 2023 15:27:47 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 31ENRkST043411; Tue, 14 Feb 2023 15:27:46 -0800 (PST) (envelope-from jmg) Date: Tue, 14 Feb 2023 15:27:46 -0800 From: John-Mark Gurney To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230214232746.GI95670@funkthat.com> Mail-Followup-To: bob prohaska , freebsd-arm@freebsd.org References: <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230214210601.GA28959@www.zefox.net> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Tue, 14 Feb 2023 15:27:47 -0800 (PST) X-Rspamd-Queue-Id: 4PGcnk3F7Kz4Pyp X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N bob prohaska wrote this message on Tue, Feb 14, 2023 at 13:06 -0800: > On Tue, Feb 14, 2023 at 10:38:27AM -0800, John-Mark Gurney wrote: > > bob prohaska wrote this message on Tue, Feb 14, 2023 at 08:14 -0800: > > > > > > Is this a demonstration that the fsck segfault can be reproduced > > > independtly of my particular corrupt filesystem? AFL is new to me. > > > > Yes, it is. It turns out that the FS to produce this failure is a LOT > > smaller than I expected when compresed, I have included it later in the > > email. The constant above was taken directly from the failing FS. > > > > AFL is a very useful tool, and found this crash and apparently 50+ > > other crashes in only 5-10 minutes of running... I'll be investigating > > a few of the other crashes as well, as fsck does ocassionally deal w/ > > untrusted fs's. > > > > Would trying to run fsck on the corrupt filesystem from an 8GB Pi4 > (also running -current) make any difference? I.e., might more physical > RAM cover up the bug and allow fsck to complete successfully? No, it will not. It's trying to access memory address 0x4 which does not exist, no matter how much memory. In this case, an inode's mtime is wildly incorrect. Here is a simple patch that will let it get farther, BUT, it doesn't necessarily mean that the kernel can properly handle the mtime: diff --git a/sbin/fsck_ffs/inode.c b/sbin/fsck_ffs/inode.c index 82338f4f8c08..d0892a822dc5 100644 --- a/sbin/fsck_ffs/inode.c +++ b/sbin/fsck_ffs/inode.c @@ -1311,7 +1311,10 @@ prtinode(struct inode *ip) printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); t = DIP(dp, di_mtime); p = ctime(&t); - printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); + if (p == NULL) + printf("MTIME=invalid "); + else + printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); } void If you can get the inode number (should be in the gdb backtrace in one of the frames), you can use fsdb to switch to the inode (inode ), and then set the mtime to something reasonable (mtime 0), and then fsck should complete as well... > Is there a plain-English description of how AFL works? I gather it > manipulates input read by a program to discover improperly handled > cases, but even that is far from certain. There's no hope of me doing > anything useful with AFL. I'm merely curious. You are correct. It insturments a program to see when it modifies the input, which branches it takes, and uses that to make better choices on how to mutate the input. In another email I sent the instructions on how I ran it, but I used: https://afl-1.readthedocs.io/en/latest/quick_start.html to figure/remind myself how to run it. Only difference is that instead of running ./configure, I used make instead in the correct directory of the FreeBSD src tree. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."