From: Shawn C <citypw@gmail.com>
To: pageexec@freemail.hu, Theodore Ts'o <tytso@mit.edu>,
Emese Revfy <re.emese@gmail.com>
Cc: linux-ext4@vger.kernel.org, Brad Spengler <spender@grsecurity.net>
Subject: Re: PAX: size overflow detected in function ext4_llseek fs/ext4/file.c:670
Date: Sat, 13 May 2017 12:23:30 +0800 [thread overview]
Message-ID: <81b23073-00e7-9cd0-71e3-b9c085a2ac34@gmail.com> (raw)
In-Reply-To: <5915875E.15260.4679D7CA@pageexec.freemail.hu>
On 05/12/2017 05:58 PM, PaX Team wrote:
> On 12 May 2017 at 1:02, Theodore Ts'o wrote:
>
> [added Emese to CC and thus kept the whole mail for context even if
> i'm responding to some parts of it only]
>
>> On Fri, May 12, 2017 at 12:10:04PM +0800, Shawn wrote:
>>>
>>> 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).
>>
>> Yes, this is indeed an interesting one. I actually suspect that
>> offset was *negative*, and since start is a u32, this got translated
>> into a large number.
>
> Shawn, can you do the printk instrumentation i suggested to print out
> the value of offset (and isize too while at it)?
>
I inserted the printk info in fs/ext4/file.c:677
00------------------
printk(KERN_DEBUG"offset: %lld, isize: %lld, blkbits: %d\n",
offset, isize, blkbits);
11------------------
result:
offset: 105, isize: 19595264, blkbits: 12
> thing is, IIRC the C standard makes right shifting a negative value
> implementation defined (so excluding such values would be good for that
> reason alone) and i think gcc simply executes it as an arithmetic shift,
> i.e., the sign of the result is preserved and thus the size overflow
> checks should have detected a minimum violation, not the maximum one.
>
> to tell for sure what check triggered exactly, i'd like to ask Shawn
> to execute
>
> make fs/ext4/file.o EXTRA_CFLAGS="-fdump-tree-all -fdump-ipa-all"
>
> and send us (Emese in particular) all the resulting files (fs/ext4/file.*)
>
find the file here:
https://ufile.io/9ie40
Let me know if you need anything else.
regards
Shawn
next prev parent reply other threads:[~2017-05-13 4:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABniQZMSW6DiSvJ7Y2TZTwUKX6sGH6-WkQRjL-kPOmdm7PnKHA@mail.gmail.com>
2017-05-12 5:02 ` PAX: size overflow detected in function ext4_llseek fs/ext4/file.c:670 Theodore Ts'o
2017-05-12 9:58 ` PaX Team
2017-05-13 4:23 ` Shawn C [this message]
2017-05-13 6:56 ` PaX Team
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=81b23073-00e7-9cd0-71e3-b9c085a2ac34@gmail.com \
--to=citypw@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=pageexec@freemail.hu \
--cc=re.emese@gmail.com \
--cc=spender@grsecurity.net \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox