linux-ext4 - Re: [PATCH 06/10] e2fsck: Handle s_inodes

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20180613121105.forqaib3bs6ljixf@quack2.suse.cz>
Date:   Wed, 13 Jun 2018 14:11:05 +0200
From:   Jan Kara <jack@...e.cz>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Jan Kara <jack@...e.cz>, Ted Tso <tytso@....edu>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 06/10] e2fsck: Handle s_inodes_count corruption properly

On Tue 12-06-18 13:04:00, Andreas Dilger wrote:
> On Jun 12, 2018, at 3:53 AM, Jan Kara <jack@...e.cz> wrote:
> > 
> > When s_inodes_count would overflow given number of groups and inodes per
> > group, we cannot currently fix the breakage in e2fsck as that requires
> > trimming number of groups or inodes per group which both means data &
> > inode migration etc. Just trimming sb->s_inodes_count is not enough as
> > kernel's inode allocation code is not able to handle filesystems where
> > not all inodes in the last group are usable. So don't pretend we can fix
> > s_inodes_count overflow by just trimming the s_inodes_count value.
> > 
> > When s_inodes_count is just wrong but will not overflow, let's fix it.
> > Also move this check before we use s_inodes_count for checking
> > s_first_ino.
> > 
> > Signed-off-by: Jan Kara <jack@...e.cz>
> 
> I guess that still leaves an open issue of what a user can do if the
> superblock (correctly or incorrectly) has groups * inodes_per_group
> that overflows 2^32, since it seems e2fsck would abort in that case.

Yes, e2fsck would abort as in the case of other non-trivial superblock
corruptions. My thinking was that in that case user can use
debugfs (hence my following debugfs changes) to fix the filesystem.

> I'd think that one option would be to reduce the group count until
> the number of inodes < 2^32, which might lose some files at the end
> of the filesystem, but more likely would not lose anything since the
> kernel would have written those inodes into the wrong place anyway.
> 
> The existing code takes the approach of truncating the last group,
> which at least makes the filesystem usable again, though it risks
> corrupting inode #1 (EXT2_BAD_INO) on older kernels should the last
> inode be allocated.  That probably isn't a huge danger in the end.

Actually currently e2fsck never succeeded in even opening the filesystem
with corrupted s_inodes_count so it could not fix anything. So my change is
at least an improvement that it reports what's wrong and fixes the "easily
fixable" corruptions.

Reducing number of block groups is doable (although libext2fs code is not
quite prepared for that so it may need some fixups). I was just a bit
worried that if the s_inodes_count corruption is not due to resize2fs bug,
reducing the group count may actually be a wrong thing to do and could
cause serious damage to the filesystem. What do people think?

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