Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#955549: f2fs-tools: fsck.f2fs segfaults
82 views
Skip to first unread message
Adam Borowski
Apr 2, 2020, 8:10:03 AM4/2/20
to
Package: f2fs-tools
Version: 1.11.0-1.1
Severity: normal
Hi!
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.
Meow!
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.2-00076-g18c13c0c087f (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages f2fs-tools depends on:
ii libblkid1 2.34-0.1
ii libc6 2.30-4
ii libf2fs-format4 1.11.0-1.1
ii libf2fs5 1.11.0-1.1
ii libselinux1 3.0-1+b2
ii libuuid1 2.34-0.1
f2fs-tools recommends no packages.
f2fs-tools suggests no packages.
-- no debconf information
Version: 1.11.0-1.1
Severity: normal
Hi!
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.
Meow!
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.2-00076-g18c13c0c087f (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages f2fs-tools depends on:
ii libblkid1 2.34-0.1
ii libc6 2.30-4
ii libf2fs-format4 1.11.0-1.1
ii libf2fs5 1.11.0-1.1
ii libselinux1 3.0-1+b2
ii libuuid1 2.34-0.1
f2fs-tools recommends no packages.
f2fs-tools suggests no packages.
-- no debconf information
Theodore Y. Ts'o
Apr 2, 2020, 3:30:03 PM4/2/20
to
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
>
> 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.
available somehow? Maybe for download at some URL? How well does it
compress?
- Ted
Adam Borowski
Apr 2, 2020, 10:50:03 PM4/2/20
to
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
> 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
> > #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
> > 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?
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
⠈⠳⣄⠀⠀⠀⠀
Chao Yu
Apr 3, 2020, 3:00:03 AM4/3/20
to
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 (ch...@kernel.org)? I guess
I can take a look at this issue.
Thanks,
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
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.
I can take a look at this issue.
Thanks,
Chao Yu
Apr 7, 2020, 6:30:03 AM4/7/20
to
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,
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> .
>
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,
> Linux-f2fs-devel mailing list
> Linux-f2...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> .
>
Adam Borowski
Apr 9, 2020, 7:40:03 PM4/9/20
to
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:
> 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
Program received signal SIGSEGV, Segmentation fault.
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....
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
> >
> > 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
Chao Yu
Apr 14, 2020, 11:40:03 PM4/14/20
to
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..
> 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
[PATCH] fsck.f2fs: fix to avoid overflow during print_inode_info()
Thanks,
Diederik de Haas
Mar 1, 2021, 8:10:03 AM3/1/21
to
On Wed, 15 Apr 2020 11:28:46 +0800 Chao Yu <yuc...@huawei.com> wrote:
> On 2020/4/10 7:32, Adam Borowski wrote:
> > I still get a segfault:
>
> Oops..
>
> > Program received signal SIGSEGV, Segmentation fault.
> > ...
> On 2020/4/10 7:32, Adam Borowski wrote:
> > I still get a segfault:
>
> Oops..
>
> > Program received signal SIGSEGV, Segmentation fault.
>
> Fixed with
>
> [PATCH] fsck.f2fs: fix to avoid overflow during print_inode_info()
This patch is included in the version of f2fs-tools that's currently in
> Fixed with
>
> [PATCH] fsck.f2fs: fix to avoid overflow during print_inode_info()
testing and unstable (and stable backports).
Can you confirm the issue is resolved?
Diederik de Haas
Mar 7, 2021, 3:20:03 PM3/7/21
to
Control: fixed -1 1.14.0-1
On zondag 7 maart 2021 20:17:39 CET Adam Borowski wrote:
> > This patch is included in the version of f2fs-tools that's currently in
> > testing and unstable (and stable backports).
> > Can you confirm the issue is resolved?
>
> Aye, fsck no longer segfaults. Thanks!
Thanks for getting back.
Updating metadata with the fixed version.
On zondag 7 maart 2021 20:17:39 CET Adam Borowski wrote:
> > This patch is included in the version of f2fs-tools that's currently in
> > testing and unstable (and stable backports).
> > Can you confirm the issue is resolved?
>
Thanks for getting back.
Updating metadata with the fixed version.
0 new messages