On 3/30/16 3:43 PM, Theodore Ts'o wrote: > 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@xxxxxxxxxx> 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.... First of all, yes, I have always been extremely skeptical of these "crafted image" CVEs. However, I'm not sure the "store errors=panic in the superblock" was particularly well thought out either; it certainly does make for a tidy little timebomb. While I really hate to give issues such as this a whole lot more credibility, I wonder about a higher level control, such as a sysctl, which could [dis]allow errors=panic at a system-wide level. It could default to disallowing, and it's trivial to set it in sysctl.conf if you really want it enabled by default. In the end, errors=panic is really a debug option; a small hoop-jump to use it doesn't sound too bad to me. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
