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

[Chao Yu]

Thanks for forwarding, Ted.

On 2020/4/3 10:45, Adam Borowski wrote:
> 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

At a glance, immediate reason of this issue is we didn't check inode.i_namelen's
validation.

>>> #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.

Would you mind sharing the password with me (chao at kernel.org)? I guess
I can take a look at this issue.

Thanks,

> 
> 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!
>