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

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

[Theodore Y. Ts'o]

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
> warning: Source file is more recent than executable.
> 34	  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
> (gdb) bt
> #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@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
> #7  main (argc=<optimized out>, argv=<optimized out>) at main.c:726
> 
> 
> I tried building current upstream git, also segfaults.
> 
> 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?

						- Ted


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] 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@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.

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
⠈⠳⣄⠀⠀⠀⠀


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [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@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 (chao@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!
> 


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

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

[Chao Yu]

Hi Adam,

I figured out two patches to fix segfault issues, could you please have
a try:

	fsck.f2fs: fix to check validation of i_xattr_nid
	fsck.f2fs: fix to check validation of block address

In addition, I found that fsck main flow failed because it can not load root
inode based on wrong block address in nat, so I wrote another patch to enable
fsck to lookup root inode by traversing all nodes in f2fs main area, and relink
nat to root inode correctly.

	fsck.f2fs: lookup and relink root inode

With this patch, image can be fixed and mounted later, although, most of files
were deleted due to seriously damaged f2fs metadata....

The patches were made on top of dev-test branch of Jaegeuk's tree:

https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test

Let me know if you have problem with above patches.

Thanks,

On 2020/4/3 14:37, Chao Yu wrote:
> 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 (chao@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!
>>
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> .
> 


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

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

[Adam Borowski]

On Tue, Apr 07, 2020 at 06:22:19PM +0800, Chao Yu wrote:
> I figured out two patches to fix segfault issues, could you please have
> a try:
> 
> 	fsck.f2fs: fix to check validation of i_xattr_nid
> 	fsck.f2fs: fix to check validation of block address
> 
> In addition, I found that fsck main flow failed because it can not load root
> inode based on wrong block address in nat, so I wrote another patch to enable
> fsck to lookup root inode by traversing all nodes in f2fs main area, and relink
> nat to root inode correctly.
> 
> 	fsck.f2fs: lookup and relink root inode

I still get a segfault:

Program received signal SIGSEGV, Segmentation fault.
0x0000555555564444 in print_inode_info (sbi=0x555555584ca0 <gfsck>, node=0x55555558f170, name=<optimized out>) at mount.c:240
240			block_t blkaddr = le32_to_cpu(inode->i_addr[i + ofs]);
(gdb) bt
#0  0x0000555555564444 in print_inode_info (sbi=0x555555584ca0 <gfsck>, node=0x55555558f170, name=<optimized out>) at mount.c:240
#1  0x0000555555564c4e in print_node_info (sbi=<optimized out>, node_block=<optimized out>, verbose=<optimized out>) at mount.c:278
#2  0x000055555556317f in dump_node (sbi=sbi@entry=0x555555584ca0 <gfsck>, nid=nid@entry=2861, force=force@entry=1) at dump.c:511
#3  0x0000555555561060 in fsck_verify (sbi=0x555555584ca0 <gfsck>) at fsck.c:3259
#4  0x000055555555799a in do_fsck (sbi=0x555555584ca0 <gfsck>) at main.c:698
#5  main (argc=<optimized out>, argv=<optimized out>) at main.c:864

> With this patch, image can be fixed and mounted later, although, most of files
> were deleted due to seriously damaged f2fs metadata....

Yeah, I've later tested the hardware -- writes to it are borked, so no
complaint against the filesystem failing.  I got backups. :)

> The patches were made on top of dev-test branch of Jaegeuk's tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test

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


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


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

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

[Chao Yu]

On 2020/4/10 7:32, Adam Borowski wrote:
> On Tue, Apr 07, 2020 at 06:22:19PM +0800, Chao Yu wrote:
>> I figured out two patches to fix segfault issues, could you please have
>> a try:
>>
>> 	fsck.f2fs: fix to check validation of i_xattr_nid
>> 	fsck.f2fs: fix to check validation of block address
>>
>> In addition, I found that fsck main flow failed because it can not load root
>> inode based on wrong block address in nat, so I wrote another patch to enable
>> fsck to lookup root inode by traversing all nodes in f2fs main area, and relink
>> nat to root inode correctly.
>>
>> 	fsck.f2fs: lookup and relink root inode
> 
> I still get a segfault:

Oops..

> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000555555564444 in print_inode_info (sbi=0x555555584ca0 <gfsck>, node=0x55555558f170, name=<optimized out>) at mount.c:240
> 240			block_t blkaddr = le32_to_cpu(inode->i_addr[i + ofs]);
> (gdb) bt
> #0  0x0000555555564444 in print_inode_info (sbi=0x555555584ca0 <gfsck>, node=0x55555558f170, name=<optimized out>) at mount.c:240
> #1  0x0000555555564c4e in print_node_info (sbi=<optimized out>, node_block=<optimized out>, verbose=<optimized out>) at mount.c:278
> #2  0x000055555556317f in dump_node (sbi=sbi@entry=0x555555584ca0 <gfsck>, nid=nid@entry=2861, force=force@entry=1) at dump.c:511
> #3  0x0000555555561060 in fsck_verify (sbi=0x555555584ca0 <gfsck>) at fsck.c:3259
> #4  0x000055555555799a in do_fsck (sbi=0x555555584ca0 <gfsck>) at main.c:698
> #5  main (argc=<optimized out>, argv=<optimized out>) at main.c:864

Fixed with

[PATCH] fsck.f2fs: fix to avoid overflow during print_inode_info()

Thanks,

> 
>> With this patch, image can be fixed and mounted later, although, most of files
>> were deleted due to seriously damaged f2fs metadata....
> 
> Yeah, I've later tested the hardware -- writes to it are borked, so no
> complaint against the filesystem failing.  I got backups. :)
> 
>> The patches were made on top of dev-test branch of Jaegeuk's tree:
>> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev-test
> 
>>>>>> #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
> 
> 
> Meow!
> 


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel