linux-ext4 - Re: [oss-security] CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160330204304.GD6207@thunk.org>
Date:	Wed, 30 Mar 2016 16:43:04 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Yves-Alexis Perez <corsac@...ian.org>,
	oss-security@...ts.openwall.com, Theodore Tso <tytso@...gle.com>,
	linux-ext4@...r.kernel.org
Subject: Re: [oss-security] CVE Request - Linux kernel (multiple versions)
 ext2/ext3  filesystem DoS

On Tue, Mar 29, 2016 at 04:56:11PM -0600, Andreas Dilger wrote:
> On Mar 29, 2016, at 3:14 PM, Yves-Alexis Perez <corsac@...ian.org> wrote:
> > 
> > [dropping MITRE from CC since it's not about the CVE]
> > [adding ext and Theodore to CC]
> > 
> > On mar., 2016-03-29 at 19:24 +0200, Hugues ANGUELKOV wrote:
> >> Hello,
> >> 
> >> The linux kernel is prone to a Denial of service when mounting specially
> >> crafted ext2/ext3 (possibly ext4) filesystems. This occurs in the function
> >> ext4_handle_error who call the panic function on precise circumstance.
> > 
> > Did you contact the upstream maintainers about this? I'm adding them just in
> > case they're not already aware of that…
> > 
> >> This was tested on severals linux kernel version: 3.10, 3.18, 3.19, on
> >> real hardware and Xen DomU PV & HVM (the crash report attached is from a
> >> Fedora 3.18 PV DomU), from different distribution release: Ubuntu, CentOS,
> >> Fedora, Linux Mint, QubesOS.
> >> This a low security impact bug, because generally only root can mount
> >> image, however on Desktop (or possibly server?) system configured with
> >> automount the bug is easily triggable (think of android smartphone? Haven't
> >> test yet).
> 
> It seems that the important point here is that the filesystem has
> "s_errors=EXT4_ERRORS_PANIC" set in the superblock?  I don't think
> the actual corruption that triggered the ext4_error() call is important,
> since there are any number of other failure cases that could generate
> a similar error.
> 
> It seems practical to change s_errors at mount time from EXT4_ERRORS_PANIC
> to EXT4_ERRORS_RO for filesystems mounted by regular users.  The question
> is whether there is a way for the ext4 code to know this at mount time?

You can mount the file system with "mount -o errors=continue" and this
will override the default behavior specified in the super block.

I would argue that a Desktop or server system that had automount
should either (a) mount with -o errors=continue, or (b) force an fsck
on the file system before mounting it.

So I think this is a particularly meaningless CVE, which is why I have
zero respect for people who try to make any kind of conclusion based
on CVE counts.   I certainly don't plan to do anything about this.

You might as well complain that since the system ships with a reboot
command that can be executed by a clueless root user, that this is a
potential DOS attack scenario deserving of a CVE....

	      	     	      		   - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html