linux-ext4 - Re: corrupt filesystem, superblock/journal

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-prev] [day] [month] [year] [list]

Message-ID: <20180524121052.crf6vp42g5ud4a5j@quack2.suse.cz>
Date:   Thu, 24 May 2018 14:10:52 +0200
From:   Jan Kara <jack@...e.cz>
To:     Jaco Kroon <jaco@....co.za>
Cc:     Jan Kara <jack@...e.cz>, linux-ext4 <linux-ext4@...r.kernel.org>,
        Pieter Kruger <pieter@....co.za>
Subject: Re: corrupt filesystem, superblock/journal - fsck

Hi,

On Wed 23-05-18 16:46:25, Jaco Kroon wrote:
> So I tracked down the fsck issue ... with a bit of additional debug
> output in the lib/ext2fs/openfs.c file, the if statement that is failing
> is this one:
> 
>     if (fs->group_desc_count * EXT2_INODES_PER_GROUP(fs->super) !=
>         fs->super->s_inodes_count) {
>         fprintf(stderr, "\ngroup to inodes problem ...
> group_desc_count=%u, inodes/group=%u, inode_count=%u\n\n",
> fs->group_desc_count, EXT2_INODES_PER_GROUP(fs->super),
> fs->super->s_inodes_count);
>         retval = EXT2_ET_CORRUPT_SUPERBLOCK;
>         goto cleanup;
>     }
> 
> And this gives us:
> 
> group to inodes problem ... group_desc_count=524288, inodes/group=8192,
> inode_count=4294967295
> 
> 524288 * 8192 = 4294967296
> 
> As a result, and value other than 0 in the inode_count file will result
> in fsck refusing to fsck the filesystem, however, mounting with that bit
> of corruption does in fact work, so whilst fsck will not function at the
> moment at least the filesystem is mounted, but this will need to be
> sorted out somehow.
> 
> I suspect this boils down to two things:
> 
> 1.  The kernel (as well as offline resize) needs to prevent resizes
> pushing inode count >= 2^32 (or if it hits exactly that just limit to
> 2^32-1).

So kernel resize had an off-by-one bug that it allowed to grow your fs to
64TB - it should have stopped you at 64TB - 128MB (one group less). Sent a
fix. Offline resize actually has the check correct.

> 2.  fsck needs to be made aware of this.

Yeah, I guess I'll make lib/ext2fs/openfs.c accept also inode count of
MAX_INT...

								Honza

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