Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Mar 2016 16:43:04 -0400
From: Theodore Ts'o <>
To: Andreas Dilger <>
Cc: Yves-Alexis Perez <>,,
	Theodore Tso <>,
Subject: Re: 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 <> 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

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ