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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.