On Mon, Nov 02, 2020 at 09:31:09AM +0800, Chao Yu wrote: > On 2020/11/1 7:48, Eric Biggers wrote: > > Hi Chao, > > > > On Tue, Apr 07, 2020 at 06:01:07PM +0800, Chao Yu wrote: > > > Otherwise, fsck.f2fs will access invalid memory address as below: > > > > > > - fsck_verify > > > - dump_node > > > - dump_file > > > - dump_inode_blk > > > - dump_xattr > > > - read_all_xattrs > > > - get_node_info > > > access &(F2FS_FSCK(sbi)->entries[nid]) > > > > > > Signed-off-by: Chao Yu <[email protected]> > > > --- > > > fsck/dump.c | 2 ++ > > > fsck/fsck.c | 8 ++++++++ > > > fsck/fsck.h | 3 +++ > > > fsck/mount.c | 8 +++++--- > > > fsck/xattr.c | 20 ++++++++++++++++++-- > > > 5 files changed, 36 insertions(+), 5 deletions(-) > > > > > > > This commit caused a regression where 'dump.f2fs -i <inode> <device>' > > now segfaults if the inode has any extended attributes. > > > > It's because read_all_xattrs() now calls fsck_sanity_check_nid(), which > > eventually dereferences f2fs_fsck::main_area_bitmap, which is NULL. > > > > I'm not sure what was intended here. > > Eric, could you please have a try with below commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/chao/f2fs-tools.git/commit/?h=dev-test&id=aad80ed0099fb9530ae3af9789362353ff580252 >
Works for me. I was wondering whether the fix would be more than that, but maybe not. - Eric _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
