[Filesystems-devel] Bug#955549: f2fs-tools: fsck.f2fs segfaults

[Adam Borowski]

On Thu, Apr 02, 2020 at 03:16:58PM -0400, Theodore Y. Ts'o wrote:
> On Thu, Apr 02, 2020 at 02:01:26PM +0200, Adam Borowski wrote:
> >
> > After a lot of output on a damaged filesystem (SD card copied to an image)
> > fsck.f2fs dies with:
> > 
> >  - File name         : mkfs.ext3.dpkg-new
> >  - File size         : 6 (bytes)
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00005555555593ec in memcpy (__len=18446744073323892736, __src=0x55555560760c, __dest=0x7fffffffe000) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> > 34	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));

> > #0  0x00005555555593ec in memcpy (__len=18446744073323892736, __src=0x55555560760c, __dest=0x7fffffffe000) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
> > #1  convert_encrypted_name (name=name at entry=0x55555560760c " ", len=-385658880, new=new at entry=0x7fffffffe000 " ", enc_name=<optimized out>) at fsck.c:1132
> > #2  0x0000555555562286 in print_inode_info (sbi=0x55555557db20 <gfsck>, node=0x5555556075b0, name=1) at mount.c:183
> > #3  0x0000555555562a46 in print_node_info (sbi=<optimized out>, node_block=<optimized out>, verbose=<optimized out>) at mount.c:277
> > #4  0x0000555555560d3f in dump_node (sbi=sbi at entry=0x55555557db20 <gfsck>, nid=nid at entry=24274, force=force at entry=1) at dump.c:520
> > #5  0x000055555555e94c in fsck_verify (sbi=0x55555557db20 <gfsck>) at fsck.c:2568
> > #6  0x000055555555699b in do_fsck (sbi=0x55555557db20 <gfsck>) at main.c:569

> > I have a copy of the filesystem in question from before any repair attempts. 
> > It has no sensitive data on it, thus I can share if needed -- 14GB.
> 
> Thanks for the bug report.  Can you make the file system image
> available somehow?  Maybe for download at some URL?  How well does it
> compress?

916MB -- https://angband.pl/rigel.f2fs.xz.gpg
The machine serves as a serial console logger/management for a bunch of
boxes; a root session is unlikely to have anything I'd not share with
developers but is not something to release to the wide world.  Thus, I
symetrically encrypted the image, I'll send you the password privately --
feel free to share it with anyone semi-trusted.

The filesystem was on a SD card, with very light use (append), no issues,
ran kernel 4.13 until 9 days ago -- then I've upgraded to 5.5.11 with no
other changes.  The corruption is probably caused by that, but there's
always a chance of SD being SD.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀                                       -- <willmore> on #linux-sunxi
⠈⠳⣄⠀⠀⠀⠀