linux-ext4 - Re: EXT4-fs (mmcblk0p1): couldn't mount as ext3 due to feature incompatibilities

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: <20180302162910.GB18112@thunk.org>
Date:   Fri, 2 Mar 2018 11:29:10 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     Joakim Tjernlund <Joakim.Tjernlund@...inera.com>
Cc:     "lczerner@...hat.com" <lczerner@...hat.com>,
        "sandeen@...hat.com" <sandeen@...hat.com>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: EXT4-fs (mmcblk0p1): couldn't mount as ext3 due to feature
 incompatibilities

On Fri, Mar 02, 2018 at 11:14:13AM -0500, Theodore Ts'o wrote:
> On Fri, Mar 02, 2018 at 03:20:22PM +0000, Joakim Tjernlund wrote:
> > 
> > But I don't hav ext3, only ext4 in kernel:
> > # CONFIG_EXT2_FS is not set
> > # CONFIG_EXT3_FS is not set
> > CONFIG_EXT4_FS=y
> 
> What version of the kernel are you using?  The ext3 file system has
> been removed from the upstream kernel for quite some time, so this
> must be a kernel missing lots of security bug fixes.  (E.g., an
> obsolete distribution kernel? :-)

Never mind, the "CONFIG_EXT3_FS is not set" confused me.  We still
have this for backwards compatibility with old kernel configs.

So I'm not seeing this behavior at all.  I created an ext4 file system
on /dev/cwcc/scratch, and then ran:

# mount -t auto /dev/cwcc/scratch /mnt

and the only thing in my dmesg from that mount is:

EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: (null)

This assumes you have a mount command that uses blkid to identify the
file system type.  If you have a mount -t auto which just blindly
probes, then sure, you can get this message if it does the equivalent of

mount -t ext2 /dev/cwcc/scratch /mnt
mount -t ext3 /dev/cwcc/scratch /mnt
mount -t ext4 /dev/cwcc/scratch /mnt

# mount -t ext3 /dev/cwcc/scratch /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/cwcc-scratch, missing codepage or helper program, or other error.

In which case you will get:

EXT4-fs (dm-4): couldn't mount as ext3 due to feature incompatibilities

But that's because mount explicitly asked for ext3.  So this may boil
down to whaht version of mount (and from what package; are you using
busybox?) and what system calls it is sending down into the kernel.

Also note that technically speaking this is not an *error* message.
If it had been an error message, it would have looked like this:

EXT4-fs error (dm-4): file system is on fire!  Run away!! Run away!!
        ^^^^^

What was printed was just an informative message; sent to syslog with
a priority of LOG_ERR, true.  But technically, still just a message
sent voa ext4_msg() as opposed to the ext4_error() function:

	if (IS_EXT3_SB(sb)) {
		if (ext3_feature_set_ok(sb))
			ext4_msg(sb, KERN_INFO, "mounting ext3 file system "
				 "using the ext4 subsystem");
		else {
			ext4_msg(sb, KERN_ERR, "couldn't mount as ext3 due "
				 "to feature incompatibilities");
			goto failed_mount;
		}
	}

In any case, this does not appear to be a kernel issue, but rather a
userspace program issue.  I can't reproduce this on my Debian testing
laptop.

Cheers,

							- Ted