linux-kernel - Re: F2FS Segmentation Fault

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 13 Jul 2020 22:54:07 -0700
From:   Jaegeuk Kim <jaegeuk@...nel.org>
To:     Nathan Royce <nroycea+kernel@...il.com>
Cc:     Chao Yu <chao@...nel.org>, linux-f2fs-devel@...ts.sourceforge.net,
        linux-kernel@...r.kernel.org
Subject: Re: F2FS Segmentation Fault

On 07/13, Nathan Royce wrote:
> On Mon, Jul 13, 2020 at 7:03 PM Jaegeuk Kim <jaegeuk@...nel.org> wrote:
> >
> > Hi Nathan,
> >
> > Could you try to say "N" here to move forward to fix the corrupted metadata?
> >
> > Thanks,
> *****
> Do you want to restore lost files into ./lost_found/? [Y/N] N
> Info: Write valid nat_bits in checkpoint
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18eca] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18ecb] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18ecc] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18ee3] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18ee4] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18ee5] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18f78] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18f79] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18f7a] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x4d621] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x4d622] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x7fa32] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x7fa33] in NAT
> Info: Write valid nat_bits in checkpoint
> 
> Done.
> *****
> 
> *****
> Info: Fix the reported corruption.
> Info: Force to fix corruption
> Info: Segments per section = 1
> Info: Sections per zone = 1
> Info: sector size = 512
> Info: total sectors = 124168159 (60628 MB)
> Info: MKFS version
>   "Linux version 5.1.15.a-1-hardened (builduser@...ve-1) (gcc version
> 9.1.0 (GCC)) #1 SMP PREEMPT Thu Jun 27 11:33:04 CEST 2019"
> Info: FSCK version
>   from "Linux version 4.19.13-dirty (nater@...x64) (gcc version 8.2.1
> 20181127 (GCC)) #2 SMP PREEMPT Mon Dec 31 00:15:50 CST 2018"
>     to "Linux version 4.19.13-dirty (nater@...x64) (gcc version 8.2.1
> 20181127 (GCC)) #2 SMP PREEMPT Mon Dec 31 00:15:50 CST 2018"
> Info: superblock features = 0 :
> Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
> Info: total FS sectors = 124168152 (60628 MB)
> Info: CKPT version = 63f2b4a
> Info: checkpoint state = 281 :  allow_nocrc nat_bits unmount
> Info: No error was reported
> *****
> I'm now booted in from my SDHC card. So it "seems" I'm good to go.
> But with the actions taken and the files I've seen displayed during
> the fsck, I'm thinking I'm going to reinstall all packages.
> Assuming the issue was related to the power outage, I do wonder why
> there weren't any fsck issues at bootup at that time. I hadn't had any
> disk issues before with that card.
> At least now I know the issue would be resolved by not saving the lost
> files and I can continue on my merry way.

I suspect the last power outage caused the FTL in the card firmware to point
the f2fs NAT table area to somewhere wrong flash cells. It may be possible
that we can't see any filesystem corruption easily, since it can corrupt
data area in higher possibility; this doesn't lead filesystem inconsistency.

I guess you use "-a" for fsck at boot up, which means scanning the disk when
runtime f2fs detects any inconsistent data. But that is true, only when the disk
guarantees SYNC_CACHE at least. Unfortunately, IMHO, such the flash card doesn't
support it gracefully, and thus, we can't rely on SYNC_CACHE which should be the
baseline to guarantee filesystem consistency. I think it'd be good to run "-f",
if sudden power cut happens in this case.

Thanks,