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