Re: [PATCH 4.4 00/24] 4.4.137-stable review

[Rafael Tinoco]

On 13 June 2018 at 18:08, Rafael David Tinoco
<rafaeldtinoco@xxxxxxxxxxxxxx> wrote:
> On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>> On Wed, Jun 13, 2018 at 05:47:49PM -0300, Rafael Tinoco wrote:
>>> Results from Linaroâs test farm.
>>> Regressions detected.
>>>
>>> NOTE:
>>>
>>> 1) LTP vma03 test (cve-2011-2496) broken on v4.4-137-rc1 because of:
>>>
>>>      6ea1dc96a03a mmap: relax file size limit for regular files
>>>      bd2f9ce5bacb mmap: introduce sane default mmap limits
>>>
>>>    discussion:
>>>
>>>      https://github.com/linux-test-project/ltp/issues/341
>>>
>>>    mainline commit (v4.13-rc7):
>>>
>>>      0cc3b0ec23ce Clarify (and fix) MAX_LFS_FILESIZE macros
>>>
>>>    should be backported to 4.4.138-rc2 and fixes the issue.
>>
>> Really?  That commit says it fixes c2a9737f45e2 ("vfs,mm: fix a dead
>> loop in truncate_inode_pages_range()") which is not in 4.4.y at all.
>>
>> Did you test this out?
>
> Yes, the LTP contains the tests (last comment is the final test for
> arm32, right before Jan tests i686).
>
> Fixing MAX_LFS_FILESIZE fixes the new limit for mmap() brought by
> those 2 commits (file_mmap_size_max()).
> offset tested by the LTP test is 0xfffffffe000.
> file_mmap_size_max gives: 0xFFFFFFFF000 as max value, but only after
> the mentioned patch.
>
> Original intent for this fix was other though.

To clarify this a bit further.

The LTP CVE test is breaking in the first call to mmap(), even before
trying to remap and test the security issue. That start happening in
this round because of those mmap() changes and the offset used in the
LTP test. Linus changed limit checks and made them to be related to
MAX_LFS_FILESIZE. Unfortunately, in 4.4 stable, we were missing the
fix for MAX_LFS_FILESIZE (which before commit 0cc3b0ec23ce was less
than the REAL 32 bit limit).

Commit 0cc3b0ec23ce was made because an user noticed the FS limit not
being what it should be. In our case, the 4.4 stable kernel, we are
facing this 32 bit lower limit (than the real 32 bit real limit),
because of the LTP CVE test, so we need this fix to have the real 32
bit limit set for that macro (mmap limits did not use that macro
before).

I have tested in arm32 and Jan Stancek, who first responded to LTP
issue, has tested this in i686 and both worked after that patch was
included to v4.4-137-rc1 (my last test was even with 4.4.138-rc1).

Hope that helps a bit.