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@entry=0x55555560760c " ", >>> len=-385658880, new=new@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@entry=0x55555557db20 <gfsck>, >>> nid=nid@entry=24274, force=force@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 (c...@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! >