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? Cheers, Andreas >> The crafted image may be burn onto SD card or USB key to crash a large >> panel of linux box. >> >> >> [ 929.200197] EXT4-fs error (device loop0): ext4_iget:4058: inode #2: comm >> mount: bad extended attribute block 8390656 >> [ 929.200226] Kernel panic - not syncing: EXT4-fs (device loop0): panic >> forced after error >> [ 929.200226] >> [ 929.200230] CPU: 1 PID: 980 Comm: mount Tainted: G O >> 3.18.17-8.pvops.qubes.x86_64 #1 >> [ 929.200233] 0000000000000000 000000007533690c ffff88000ea07aa8 >> ffffffff81722191 >> [ 929.200237] 0000000000000000 ffffffff81a84108 ffff88000ea07b28 >> ffffffff8171a462 >> [ 929.200240] ffff880000000010 ffff88000ea07b38 ffff88000ea07ad8 >> 000000007533690c >> [ 929.200244] Call Trace: >> [ 929.200249] [<ffffffff81722191>] dump_stack+0x46/0x58 >> [ 929.200253] [<ffffffff8171a462>] panic+0xd0/0x204 >> [ 929.200257] [<ffffffff812ae4d6>] ext4_handle_error.part.188+0x96/0xa0 >> [ 929.200260] [<ffffffff812ae838>] __ext4_error_inode+0xa8/0x180 >> [ 929.200264] [<ffffffff81292869>] ext4_iget+0x929/0xae0 >> [ 929.200267] [<ffffffff812b31fb>] ext4_fill_super+0x18db/0x2b60 >> [ 929.200270] [<ffffffff8120af20>] mount_bdev+0x1b0/0x1f0 >> [ 929.200273] [<ffffffff812b1920>] ? ext4_calculate_overhead+0x3d0/0x3d0 >> [ 929.200276] [<ffffffff812a3425>] ext4_mount+0x15/0x20 >> [ 929.200278] [<ffffffff8120b879>] mount_fs+0x39/0x1b0 >> [ 929.200282] [<ffffffff811afd95>] ? __alloc_percpu+0x15/0x20 >> [ 929.200285] [<ffffffff8122754b>] vfs_kern_mount+0x6b/0x110 >> [ 929.200287] [<ffffffff8122a38c>] do_mount+0x22c/0xb60 >> [ 929.200290] [<ffffffff811aab96>] ? memdup_user+0x46/0x80 >> [ 929.200292] [<ffffffff8122b002>] SyS_mount+0xa2/0x110 >> [ 929.200295] [<ffffffff8172a609>] system_call_fastpath+0x12/0x17 >> [ 929.200301] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation >> range: 0xffffffff80000000-0xffffffff9fffffff)c >> >> I cannot attach the PoC (2x2MB too large) nor sending it in plain text >> (they are filesystems), so I've uploaded it on this website of free file >> sharing ... (sorry for the inconvenient): >> poc.ext2 https://1fichier.com/?zbk2gohk8s >> poc.ext3 https://1fichier.com/?9r0c8agjfa >> >> Can you assign a CVE for this? >> Thank for reading and your time. >> >> Hugues ANGUELKOV. >> >> > -- > Yves-Alexis > Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
