linux-ext4 - Re: ext4 corruption causing a crash

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5ce3de05-2f37-6758-1178-ecf520c87d4f@kyup.com>
Date:   Thu, 17 Nov 2016 09:12:34 +0200
From:   Nikolay Borisov <kernel@...p.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Jan Kara <jack@...e.com>, linux-ext4 <linux-ext4@...r.kernel.org>,
        bp@...en8.de
Subject: Re: ext4 corruption causing a crash



On 11/16/2016 08:17 PM, Theodore Ts'o wrote:
> On Wed, Nov 16, 2016 at 03:03:35PM +0200, Nikolay Borisov wrote:
>>
>> Ok so with the help of bpetkov we managed to get to the bottom it, 
>> essentially what happens is that we overflow the page allocated in 
>> ext4_calculate_overhead while working in the following loop in count_overhead: 
>>
>> for (j = ext4_bg_num_gdb(sb, grp); j > 0; j--) {
>> 	ext4_set_bit(EXT4_B2C(sbi, s++), buf);
>> 	count++;
>> }
>>
>> so ext4_bg_num_gdb returns a big number - 32768 and since sbi->s_cluster_bits 
>> is 0 the result of EXT4_B2C(sbi, s++) becomes just s, which incremented on 
>> every iteration and eventually becomes a large number. This causes to overflow 
>> the page used as a buf. This can be seen easily from the crash produced when 
>> debug_pagealloc is enabled:
> 
> Thanks for digging into this!  It sounds like we need to add more
> sanity checking at mount time, as well as some safety constraints to
> make sure we don't overrun memory.
> 
> Can you send me dumpe2fs -h output from the drive that provoked this?

Sorry, no. 

dumpe2fs -h -f OSS-2016-22-image 
dumpe2fs 1.42.12 (29-Aug-2014)
dumpe2fs: Filesystem revision too high while trying to open OSS-2016-22-image
Couldn't find valid filesystem superblock.

Here is what 'file' reports though: 
 
OSS-2016-22-image: Linux rev 65537.0 ext2 filesystem data (extents) (huge files)

Also you can find the offending image here: 
https://os-s.net/advisories/OSS-2016-23-image


> 
> Thanks,
> 
> 						- Ted
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html