linux-ext4 - Re: e2fsck fails on non journalled partition

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:   Sun, 17 Mar 2019 17:53:15 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Ede Wolf <listac@...elschwaden.de>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: e2fsck fails on non journalled partition

I'm really curious how the superblock got into this configuration:

> > > ~ # tune2fs -l /dev/sde1
> > > tune2fs 1.44.5 (15-Dec-2018)
> > > Filesystem volume name:   USERDATA
  ...
> > > Filesystem features:      ext_attr resize_inode dir_index filetype extent 64bit large_dir sparse_super large_file

There is no journal features here at all

> > > Journal UUID:             00000000-1b00-0000-0000-000000000000
> > > Journal inode:            131072

A journal UUID and inode should never be set at the same time.  But
this is a lot more than a single bit flip.  The rest of the sueprblock
looks sane, so it's not a matter of someone writing garbage over the
on-disk copy.

Maybe a wild pointer smashing two bytes in the middle of the
superblock?

In any case, this is something where we should probably add sanity
checks so kernel will refuse to mount a file system like this --- and
e2fsck should also try to see if the backup superblock is sane and try
using it.  (We could also teach e2fsck to offer to clear these fields so
a user won't have to use debugfs's ssv command if falling back to
backup superblock doesn't work.)

I'm still really wondering how this could have happened, though...

    	  	 	       	    	  - Ted