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 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).