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]
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

Powered by blists - more mailing lists