Date:   Fri, 12 May 2017 12:10:04 +0800
From:   Shawn <citypw@...il.com>
To:     tytso@...nk.org, linux-kernel@...r.kernel.org
Cc:     Pipacs <pageexec@...il.com>, Brad Spengler <spender@...ecurity.net>
Subject: PAX: size overflow detected in function ext4_llseek fs/ext4/file.c:670

Hi,

One of PaX/Grsecurity feature( PAX_SIZE_OVERFLOW) caught a bug in ext4
file system:

May 10 12:05:49 debian8-test kernel: [  130.765865] PAX: size overflow
detected in function ext4_llseek fs/ext4/file.c:670 cicus.162_143 max,
count: 13, decl: ext4_get_next_extent; num: 3; context: fndecl;
May 10 12:05:49 debian8-test kernel: [  130.767905] CPU: 0 PID: 1643
Comm: trinity-c4 Not tainted 4.10.14-grsec #1
May 10 12:05:49 debian8-test kernel: [  130.767919] Hardware name:
QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1
04/01/2014
May 10 12:05:49 debian8-test kernel: [  130.767920] Call Trace:
May 10 12:05:49 debian8-test kernel: [  130.767946]
[<ffffffff8148f716>] ? dump_stack+0x7b/0xc5
May 10 12:05:49 debian8-test kernel: [  130.767950]
[<ffffffff8129eaf9>] ? report_size_overflow+0x99/0xd0
May 10 12:05:49 debian8-test kernel: [  130.767957]
[<ffffffffa031f587>] ? ext4_exit_fs+0x3700/0x279e0 [ext4]
May 10 12:05:49 debian8-test kernel: [  130.767959]
[<ffffffff8129eb0b>] ? report_size_overflow+0xab/0xd0
May 10 12:05:49 debian8-test kernel: [  130.767962]
[<ffffffffa02aac55>] ? ext4_llseek+0x895/0xd90 [ext4]
May 10 12:05:49 debian8-test kernel: [  130.767966]
[<ffffffff810019c3>] ? syscall_trace_enter+0x203/0x330
May 10 12:05:49 debian8-test kernel: [  130.767970]
[<ffffffff811864ce>] ? __audit_syscall_entry+0xfe/0x160
May 10 12:05:49 debian8-test kernel: [  130.767971]
[<ffffffff8100195d>] ? syscall_trace_enter+0x19d/0x330
May 10 12:05:49 debian8-test kernel: [  130.767973]
[<ffffffff81290820>] ? rap_sys_lseek+0xf0/0x140
May 10 12:05:49 debian8-test kernel: [  130.767974]
[<ffffffff81001ec1>] ? do_syscall_64+0x91/0x180
May 10 12:05:49 debian8-test kernel: [  130.767976]
[<ffffffff81908573>] ? entry_SYSCALL64_slow_path+0x32/0x32

Kernel: linux-4.10.14
Testing on: Debian 8

Kernel log was attached! You can find the full Trinity fuzzer logs here:

https://github.com/hardenedlinux/community-QA/tree/master/bug_report/trinity-log-20170511

Some technical analysis from PaX team:
-------------------------------------------------------------------------------

thanks for the reports, keep them coming . this is an interesting one,
here's the code (same at both lines in ext4_seek_hole and ext4_seek_data):

670 »·······start = offset >> blkbits;

in types this is

u32 = long long >> int;

since the maximum value was exceeded it means that offset (long long,
64 bits even on 32 bit archs) had a value that didn't fit u32 when right
shifted. based on some light code reading, blkbits is between 10-16 on
ext4 (EXT4_MIN_BLOCK_SIZE-EXT4_MAX_BLOCK_SIZE) so depending on what the
actual block size of the underlying filesystem was, offset must have been
bigger than 2^42-2^48 (4TB-256TB).

now i don't know how the maximum file size scales with the block size
but apparently it was possible to create a file big enough that'd cause
the integer truncation error caught above. my opinion is that this is
a bug in ext4 and you should report it to Ted T'so and work with him on
the proper fix (he can also tell what the consequences of this truncation
are, if any). to actually confirm the integer truncation you should add
a printk above those lines and print out the values of offset and blkbits.
to reduce log spam you can make it conditional on offset >= 1LL << blkbits.

cheers,
 PaX Team
-------------------------------------------------------------------------------



-- 
GNU powered it...
GPL protect it...
God blessing it...

regards
Shawn

View attachment "kern.log" of type "text/x-log" (355674 bytes)

Powered by blists - more mailing lists