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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 16 Nov 2016 13:17:50 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     Nikolay Borisov <kernel@...p.com>
Cc:     Jan Kara <jack@...e.com>, linux-ext4 <linux-ext4@...r.kernel.org>,
        bp@...en8.de
Subject: Re: ext4 corruption causing a crash

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?

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