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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists