linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Yves-Alexis Perez <corsac@debian.org>,
	oss-security@lists.openwall.com, Theodore Tso <tytso@google.com>,
	linux-ext4@vger.kernel.org
Subject: Re: [oss-security] CVE Request - Linux kernel (multiple versions) ext2/ext3  filesystem DoS
Date: Wed, 30 Mar 2016 16:43:04 -0400	[thread overview]
Message-ID: <20160330204304.GD6207@thunk.org> (raw)
In-Reply-To: <57514A3C-DBAD-4E5E-98EA-23E490629C02@dilger.ca>

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@debian.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-03-30 20:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f4df42b35dd9a6c8c6851eba66b2b3f1.squirrel@webmail-etu.univ-nantes.fr>
2016-03-29 21:14 ` [oss-security] CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Yves-Alexis Perez
2016-03-29 22:56   ` Andreas Dilger
2016-03-30 20:43     ` Theodore Ts'o [this message]
2016-03-31 14:41       ` Eric Sandeen
     [not found]         ` <56FD3718.2090502-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-31 16:51           ` Theodore Ts'o
     [not found]       ` <20160330204304.GD6207-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2016-03-31 14:53         ` Kurt Seifried
     [not found]           ` <CANO=Ty1OcZ=ukxttq9A9M9ot78jDPzDmq4y1NGUMAQmSiveH_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-31 15:47             ` Andreas Dilger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160330204304.GD6207@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=corsac@debian.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=oss-security@lists.openwall.com \
    --cc=tytso@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).