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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
