linux-ext4 - Fixing SB with e2fsck

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180528152400.5fgjd3yw2mncggyr@quack2.suse.cz>
Date:   Mon, 28 May 2018 17:24:00 +0200
From:   Jan Kara <jack@...e.cz>
To:     Ted Tso <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org
Subject: Fixing SB with e2fsck

Hi Ted,

I was looking into fixing the problem with resize2fs overflowing
s_inodes_count with e2fsck. The problem there is that e2fsck does not even
open the filesystem as ext2fs_open2() finds s_inodes_count is corrupted and
aborts. That seems like a fundamental problem with e2fsck using
ext2fs_open2() so it is not able to fix corruptions in superblock. Usually
this can be resolved by resorting to a backup superblock but with this
resize2fs problem, backup superblocks are buggy in the same way so there's
no way to fix the filesystem besides binary poking bytes into it (even
debugfs won't work). So what should we do?

1) Just live with the fact that such corruptions are not easily fixable.
2) Add a flag to ext2fs_open() to check only a bare minimum in the
superblock so that e2fsck can start working and fixup the superblock.
3) Something else I'm missing.

What do you think?

								Honza

-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR