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

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

[Rafael Tinoco]

FYI on issue #341

Thanks Jan for pointing out commit 0cc3b0ec23ce right after I opened the issue.

Best,
-Rafael

---------- Forwarded message ----------
From: Rafael Tinoco <rafael.tinoco@linaro.org>
Date: 13 June 2018 at 17:47
Subject: Re: [PATCH 4.4 00/24] 4.4.137-stable review
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, shuah@kernel.org,
patches@kernelci.org, lkft-triage@lists.linaro.org,
ben.hutchings@codethink.co.uk, stable@vger.kernel.org,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
linux@roeck-us.net


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.

2) select04 failure on x15 board will be investigated in:

     https://bugs.linaro.org/show_bug.cgi?id=3852

   and seems to be a timing issue (HW related).

Summary
------------------------------------------------------------------------

kernel: 4.4.137-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 678437d36d4e14a029309f1c282802ce47fda36a
git describe: v4.4.136-25-g678437d36d4e
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.136-25-g678437d36d4e

Regressions (compared to build v4.4.136)
------------------------------------------------------------------------

qemu_arm:
  ltp-cve-tests:
    * cve-2011-2496
    * runltp_cve

    * test src: git://github.com/linux-test-project/ltp.git

x15 - arm:
  ltp-cve-tests:
    * cve-2011-2496
    * runltp_cve

    * test src: git://github.com/linux-test-project/ltp.git
  ltp-syscalls-tests:
    * runltp_syscalls
    * select04

    * test src: git://github.com/linux-test-project/ltp.git

Ran 7100 total tests in the following environments and test suites.

Environments
--------------
- juno-r2 - arm64
- qemu_arm
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

Summary
------------------------------------------------------------------------

kernel: 4.4.137-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.137-rc1-hikey-20180612-214
git commit: e5d5cb57472f9f98a68f872664de3d70610019e1
git describe: 4.4.137-rc1-hikey-20180612-214
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.137-rc1-hikey-20180612-214

No regressions (compared to build 4.4.136-rc2-hikey-20180606-212)

Ran 2611 total tests in the following environments and test suites.

Environments
--------------
- hi6220-hikey - arm64
- qemu_arm64

Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-fs-tests

--
Linaro LKFT
https://lkft.linaro.org

On 12 June 2018 at 13:51, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 4.4.137 release.
> There are 24 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Jun 14 16:48:07 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>         https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.137-rc1.gz
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

[LTP] [PATCH 4.4 00/24] 4.4.137-stable review

[Rafael Tinoco]

I forgot to cc LTP mailing list in the thread. Here is the thread url at least:

https://lkml.org/lkml/2018/6/13/714

Thank you
-Rafael

On 13 June 2018 at 17:52, Rafael Tinoco <rafael.tinoco@linaro.org> wrote:
> FYI on issue #341
>
> Thanks Jan for pointing out commit 0cc3b0ec23ce right after I opened the issue.
>
> Best,
> -Rafael
>
> ---------- Forwarded message ----------
> From: Rafael Tinoco <rafael.tinoco@linaro.org>
> Date: 13 June 2018 at 17:47
> Subject: Re: [PATCH 4.4 00/24] 4.4.137-stable review
> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-kernel@vger.kernel.org, shuah@kernel.org,
> patches@kernelci.org, lkft-triage@lists.linaro.org,
> ben.hutchings@codethink.co.uk, stable@vger.kernel.org,
> akpm@linux-foundation.org, torvalds@linux-foundation.org,
> linux@roeck-us.net
>
>
> 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.
>
> 2) select04 failure on x15 board will be investigated in:
>
>      https://bugs.linaro.org/show_bug.cgi?id=3852
>
>    and seems to be a timing issue (HW related).
>
> Summary
> ------------------------------------------------------------------------
>
> kernel: 4.4.137-rc1
> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> git branch: linux-4.4.y
> git commit: 678437d36d4e14a029309f1c282802ce47fda36a
> git describe: v4.4.136-25-g678437d36d4e
> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.136-25-g678437d36d4e
>
> Regressions (compared to build v4.4.136)
> ------------------------------------------------------------------------
>
> qemu_arm:
>   ltp-cve-tests:
>     * cve-2011-2496
>     * runltp_cve
>
>     * test src: git://github.com/linux-test-project/ltp.git
>
> x15 - arm:
>   ltp-cve-tests:
>     * cve-2011-2496
>     * runltp_cve
>
>     * test src: git://github.com/linux-test-project/ltp.git
>   ltp-syscalls-tests:
>     * runltp_syscalls
>     * select04
>
>     * test src: git://github.com/linux-test-project/ltp.git
>
> Ran 7100 total tests in the following environments and test suites.
>
> Environments
> --------------
> - juno-r2 - arm64
> - qemu_arm
> - qemu_x86_64
> - x15 - arm
> - x86_64
>
> Test Suites
> -----------
> * boot
> * kselftest
> * libhugetlbfs
> * ltp-cap_bounds-tests
> * ltp-containers-tests
> * ltp-cve-tests
> * ltp-fcntl-locktests-tests
> * ltp-filecaps-tests
> * ltp-fs-tests
> * ltp-fs_bind-tests
> * ltp-fs_perms_simple-tests
> * ltp-fsx-tests
> * ltp-hugetlb-tests
> * ltp-io-tests
> * ltp-ipc-tests
> * ltp-math-tests
> * ltp-nptl-tests
> * ltp-pty-tests
> * ltp-sched-tests
> * ltp-securebits-tests
> * ltp-syscalls-tests
> * ltp-timers-tests
> * kselftest-vsyscall-mode-native
> * kselftest-vsyscall-mode-none
>
> Summary
> ------------------------------------------------------------------------
>
> kernel: 4.4.137-rc1
> git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
> git branch: 4.4.137-rc1-hikey-20180612-214
> git commit: e5d5cb57472f9f98a68f872664de3d70610019e1
> git describe: 4.4.137-rc1-hikey-20180612-214
> Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.137-rc1-hikey-20180612-214
>
> No regressions (compared to build 4.4.136-rc2-hikey-20180606-212)
>
> Ran 2611 total tests in the following environments and test suites.
>
> Environments
> --------------
> - hi6220-hikey - arm64
> - qemu_arm64
>
> Test Suites
> -----------
> * boot
> * kselftest
> * libhugetlbfs
> * ltp-cap_bounds-tests
> * ltp-containers-tests
> * ltp-cve-tests
> * ltp-fcntl-locktests-tests
> * ltp-filecaps-tests
> * ltp-fs_bind-tests
> * ltp-fs_perms_simple-tests
> * ltp-fsx-tests
> * ltp-hugetlb-tests
> * ltp-io-tests
> * ltp-ipc-tests
> * ltp-math-tests
> * ltp-nptl-tests
> * ltp-pty-tests
> * ltp-sched-tests
> * ltp-securebits-tests
> * ltp-syscalls-tests
> * ltp-timers-tests
> * ltp-fs-tests
>
> --
> Linaro LKFT
> https://lkft.linaro.org
>
> On 12 June 2018 at 13:51, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>> This is the start of the stable review cycle for the 4.4.137 release.
>> There are 24 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Thu Jun 14 16:48:07 UTC 2018.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>>         https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.137-rc1.gz
>> or in the git tree and branch at:
>>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h

[LTP] [PATCH 4.4 00/24] 4.4.137-stable review

[Rafael Tinoco]

On 13 June 2018 at 18:08, Rafael David Tinoco
<rafaeldtinoco@kernelpath.com> wrote:
> On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> 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.

[LTP] [PATCH 4.4 00/24] 4.4.137-stable review

[Greg Kroah-Hartman]

On Wed, Jun 13, 2018 at 10:48:50PM -0300, Rafael Tinoco wrote:
> On 13 June 2018 at 18:08, Rafael David Tinoco
> <rafaeldtinoco@kernelpath.com> wrote:
> > On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> 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.

Ok, thanks, it didn't apply cleanly but I've fixed it up now.

greg k-h

[LTP] [PATCH 4.4 00/24] 4.4.137-stable review

[Naresh Kamboju]

On 14 June 2018 at 12:04, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Wed, Jun 13, 2018 at 10:48:50PM -0300, Rafael Tinoco wrote:
>> On 13 June 2018 at 18:08, Rafael David Tinoco
>> <rafaeldtinoco@kernelpath.com> wrote:
>> > On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
>> > <gregkh@linuxfoundation.org> 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.
>
> Ok, thanks, it didn't apply cleanly but I've fixed it up now.

On the latest 4.4.138-rc1,
LTP "cve-2011-2496" test still fails on arm32 beagleboard x15 and qemu_arm.

Summary
------------------------------------------------------------------------
kernel: 4.4.138-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 7d690c56754ef7be647fbcf7bcdceebd59926b3f
git describe: v4.4.137-15-g7d690c56754e
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.137-15-g7d690c56754e

On the side note,
Kernel selftests version upgrade to 4.17.

- Naresh

[LTP] [PATCH 4.4 00/24] 4.4.137-stable review

[Greg Kroah-Hartman]

On Thu, Jun 14, 2018 at 02:24:25PM +0530, Naresh Kamboju wrote:
> On 14 June 2018 at 12:04, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Wed, Jun 13, 2018 at 10:48:50PM -0300, Rafael Tinoco wrote:
> >> On 13 June 2018 at 18:08, Rafael David Tinoco
> >> <rafaeldtinoco@kernelpath.com> wrote:
> >> > On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> >> > <gregkh@linuxfoundation.org> 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.
> >
> > Ok, thanks, it didn't apply cleanly but I've fixed it up now.
> 
> On the latest 4.4.138-rc1,
> LTP "cve-2011-2496" test still fails on arm32 beagleboard x15 and qemu_arm.
> 
> Summary
> ------------------------------------------------------------------------
> kernel: 4.4.138-rc1
> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> git branch: linux-4.4.y
> git commit: 7d690c56754ef7be647fbcf7bcdceebd59926b3f
> git describe: v4.4.137-15-g7d690c56754e
> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.137-15-g7d690c56754e

Ok, but what does this mean?  Is there a commit somewhere that I need to
pick up for 4.4.y that is already in newer kernels?

I have no idea what that cve is, as I never track them, and it's
something that was reported to predate the 4.4 kernel release :)

thanks,

greg k-h

[LTP] [PATCH 4.4 00/24] 4.4.137-stable review

[Jan Stancek]

----- Original Message -----
> On Thu, Jun 14, 2018 at 02:24:25PM +0530, Naresh Kamboju wrote:
> > On 14 June 2018 at 12:04, Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > wrote:
> > > On Wed, Jun 13, 2018 at 10:48:50PM -0300, Rafael Tinoco wrote:
> > >> On 13 June 2018 at 18:08, Rafael David Tinoco
> > >> <rafaeldtinoco@kernelpath.com> wrote:
> > >> > On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> > >> > <gregkh@linuxfoundation.org> 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.
> > >
> > > Ok, thanks, it didn't apply cleanly but I've fixed it up now.
> > 
> > On the latest 4.4.138-rc1,
> > LTP "cve-2011-2496" test still fails on arm32 beagleboard x15 and qemu_arm.
> > 
> > Summary
> > ------------------------------------------------------------------------
> > kernel: 4.4.138-rc1
> > git repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > git branch: linux-4.4.y
> > git commit: 7d690c56754ef7be647fbcf7bcdceebd59926b3f
> > git describe: v4.4.137-15-g7d690c56754e
> > Test details:
> > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.137-15-g7d690c56754e
> 
> Ok, but what does this mean?  Is there a commit somewhere that I need to
> pick up for 4.4.y that is already in newer kernels?

Hi Greg,

I think the expectations was that:
  0cc3b0ec23ce Clarify (and fix) MAX_LFS_FILESIZE macros
has been included to linux-4.4.y HEAD, so they re-ran the tests.

Report from Naresh above looks like original report: LTP vma03 is cve-2011-2496 test.

Regards,
Jan

> 
> I have no idea what that cve is
>, as I never track them, and it's
> something that was reported to predate the 4.4 kernel release :)
> 
> thanks,
> 
> greg k-h
> 
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
> 

[LTP] [PATCH 4.4 00/24] 4.4.137-stable review

[Greg Kroah-Hartman]

On Thu, Jun 14, 2018 at 05:49:52AM -0400, Jan Stancek wrote:
> 
> ----- Original Message -----
> > On Thu, Jun 14, 2018 at 02:24:25PM +0530, Naresh Kamboju wrote:
> > > On 14 June 2018 at 12:04, Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > wrote:
> > > > On Wed, Jun 13, 2018 at 10:48:50PM -0300, Rafael Tinoco wrote:
> > > >> On 13 June 2018 at 18:08, Rafael David Tinoco
> > > >> <rafaeldtinoco@kernelpath.com> wrote:
> > > >> > On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> > > >> > <gregkh@linuxfoundation.org> 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.
> > > >
> > > > Ok, thanks, it didn't apply cleanly but I've fixed it up now.
> > > 
> > > On the latest 4.4.138-rc1,
> > > LTP "cve-2011-2496" test still fails on arm32 beagleboard x15 and qemu_arm.
> > > 
> > > Summary
> > > ------------------------------------------------------------------------
> > > kernel: 4.4.138-rc1
> > > git repo:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > git branch: linux-4.4.y
> > > git commit: 7d690c56754ef7be647fbcf7bcdceebd59926b3f
> > > git describe: v4.4.137-15-g7d690c56754e
> > > Test details:
> > > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.137-15-g7d690c56754e
> > 
> > Ok, but what does this mean?  Is there a commit somewhere that I need to
> > pick up for 4.4.y that is already in newer kernels?
> 
> Hi Greg,
> 
> I think the expectations was that:
>   0cc3b0ec23ce Clarify (and fix) MAX_LFS_FILESIZE macros
> has been included to linux-4.4.y HEAD, so they re-ran the tests.
> 
> Report from Naresh above looks like original report: LTP vma03 is cve-2011-2496 test.

And the test fails now?

Still confused.

greg k-h

[LTP] [PATCH 4.4 00/24] 4.4.137-stable review

[Jan Stancek]

----- Original Message -----
> On Thu, Jun 14, 2018 at 05:49:52AM -0400, Jan Stancek wrote:
> > 
> > ----- Original Message -----
> > > On Thu, Jun 14, 2018 at 02:24:25PM +0530, Naresh Kamboju wrote:
> > > > On 14 June 2018 at 12:04, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org>
> > > > wrote:
> > > > > On Wed, Jun 13, 2018 at 10:48:50PM -0300, Rafael Tinoco wrote:
> > > > >> On 13 June 2018 at 18:08, Rafael David Tinoco
> > > > >> <rafaeldtinoco@kernelpath.com> wrote:
> > > > >> > On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> > > > >> > <gregkh@linuxfoundation.org> 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.
> > > > >
> > > > > Ok, thanks, it didn't apply cleanly but I've fixed it up now.
> > > > 
> > > > On the latest 4.4.138-rc1,
> > > > LTP "cve-2011-2496" test still fails on arm32 beagleboard x15 and
> > > > qemu_arm.
> > > > 
> > > > Summary
> > > > ------------------------------------------------------------------------
> > > > kernel: 4.4.138-rc1
> > > > git repo:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > > git branch: linux-4.4.y
> > > > git commit: 7d690c56754ef7be647fbcf7bcdceebd59926b3f
> > > > git describe: v4.4.137-15-g7d690c56754e
> > > > Test details:
> > > > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.137-15-g7d690c56754e
> > > 
> > > Ok, but what does this mean?  Is there a commit somewhere that I need to
> > > pick up for 4.4.y that is already in newer kernels?
> > 
> > Hi Greg,
> > 
> > I think the expectations was that:
> >   0cc3b0ec23ce Clarify (and fix) MAX_LFS_FILESIZE macros
> > has been included to linux-4.4.y HEAD, so they re-ran the tests.
> > 
> > Report from Naresh above looks like original report: LTP vma03 is
> > cve-2011-2496 test.
> 
> And the test fails now?
> 
> Still confused.

I don't see the patch (0cc3b0ec23ce) applied to linux-stable-rc.git,
branch linux-4.4.y:
  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=linux-4.4.y
  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/tree/include/linux/fs.h?h=linux-4.4.y&id=7d690c56754ef7be647fbcf7bcdceebd59926b3f#n929

That is what has been tested above - is that the correct place
to get your backport of 0cc3b0ec23ce?

Regards,
Jan

[LTP] [PATCH 4.4 00/24] 4.4.137-stable review

[Rafael Tinoco]

Jan, Naresh,

Patch has been queued to 4.4 (for the next review round, yet to be
merged to stable-rc branch):

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-4.4

as "clarify-and-fix-max_lfs_filesize-macros.patch"

Thank you!

On 14 June 2018 at 07:36, Jan Stancek <jstancek@redhat.com> wrote:
>
> ----- Original Message -----
>> On Thu, Jun 14, 2018 at 05:49:52AM -0400, Jan Stancek wrote:
>> >
>> > ----- Original Message -----
>> > > On Thu, Jun 14, 2018 at 02:24:25PM +0530, Naresh Kamboju wrote:
>> > > > On 14 June 2018 at 12:04, Greg Kroah-Hartman
>> > > > <gregkh@linuxfoundation.org>
>> > > > wrote:
>> > > > > On Wed, Jun 13, 2018 at 10:48:50PM -0300, Rafael Tinoco wrote:
>> > > > >> On 13 June 2018 at 18:08, Rafael David Tinoco
>> > > > >> <rafaeldtinoco@kernelpath.com> wrote:
>> > > > >> > On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
>> > > > >> > <gregkh@linuxfoundation.org> 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.
>> > > > >
>> > > > > Ok, thanks, it didn't apply cleanly but I've fixed it up now.
>> > > >
>> > > > On the latest 4.4.138-rc1,
>> > > > LTP "cve-2011-2496" test still fails on arm32 beagleboard x15 and
>> > > > qemu_arm.
>> > > >
>> > > > Summary
>> > > > ------------------------------------------------------------------------
>> > > > kernel: 4.4.138-rc1
>> > > > git repo:
>> > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> > > > git branch: linux-4.4.y
>> > > > git commit: 7d690c56754ef7be647fbcf7bcdceebd59926b3f
>> > > > git describe: v4.4.137-15-g7d690c56754e
>> > > > Test details:
>> > > > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.137-15-g7d690c56754e
>> > >
>> > > Ok, but what does this mean?  Is there a commit somewhere that I need to
>> > > pick up for 4.4.y that is already in newer kernels?
>> >
>> > Hi Greg,
>> >
>> > I think the expectations was that:
>> >   0cc3b0ec23ce Clarify (and fix) MAX_LFS_FILESIZE macros
>> > has been included to linux-4.4.y HEAD, so they re-ran the tests.
>> >
>> > Report from Naresh above looks like original report: LTP vma03 is
>> > cve-2011-2496 test.
>>
>> And the test fails now?
>>
>> Still confused.
>
> I don't see the patch (0cc3b0ec23ce) applied to linux-stable-rc.git,
> branch linux-4.4.y:
>   https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=linux-4.4.y
>   https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/tree/include/linux/fs.h?h=linux-4.4.y&id=7d690c56754ef7be647fbcf7bcdceebd59926b3f#n929
>
> That is what has been tested above - is that the correct place
> to get your backport of 0cc3b0ec23ce?
>
> Regards,
> Jan

[LTP] [PATCH 4.4 00/24] 4.4.137-stable review

[Greg Kroah-Hartman]

On Thu, Jun 14, 2018 at 06:36:03AM -0400, Jan Stancek wrote:
> 
> ----- Original Message -----
> > On Thu, Jun 14, 2018 at 05:49:52AM -0400, Jan Stancek wrote:
> > > 
> > > ----- Original Message -----
> > > > On Thu, Jun 14, 2018 at 02:24:25PM +0530, Naresh Kamboju wrote:
> > > > > On 14 June 2018 at 12:04, Greg Kroah-Hartman
> > > > > <gregkh@linuxfoundation.org>
> > > > > wrote:
> > > > > > On Wed, Jun 13, 2018 at 10:48:50PM -0300, Rafael Tinoco wrote:
> > > > > >> On 13 June 2018 at 18:08, Rafael David Tinoco
> > > > > >> <rafaeldtinoco@kernelpath.com> wrote:
> > > > > >> > On Wed, Jun 13, 2018 at 6:00 PM, Greg Kroah-Hartman
> > > > > >> > <gregkh@linuxfoundation.org> 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.
> > > > > >
> > > > > > Ok, thanks, it didn't apply cleanly but I've fixed it up now.
> > > > > 
> > > > > On the latest 4.4.138-rc1,
> > > > > LTP "cve-2011-2496" test still fails on arm32 beagleboard x15 and
> > > > > qemu_arm.
> > > > > 
> > > > > Summary
> > > > > ------------------------------------------------------------------------
> > > > > kernel: 4.4.138-rc1
> > > > > git repo:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > > > git branch: linux-4.4.y
> > > > > git commit: 7d690c56754ef7be647fbcf7bcdceebd59926b3f
> > > > > git describe: v4.4.137-15-g7d690c56754e
> > > > > Test details:
> > > > > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.137-15-g7d690c56754e
> > > > 
> > > > Ok, but what does this mean?  Is there a commit somewhere that I need to
> > > > pick up for 4.4.y that is already in newer kernels?
> > > 
> > > Hi Greg,
> > > 
> > > I think the expectations was that:
> > >   0cc3b0ec23ce Clarify (and fix) MAX_LFS_FILESIZE macros
> > > has been included to linux-4.4.y HEAD, so they re-ran the tests.
> > > 
> > > Report from Naresh above looks like original report: LTP vma03 is
> > > cve-2011-2496 test.
> > 
> > And the test fails now?
> > 
> > Still confused.
> 
> I don't see the patch (0cc3b0ec23ce) applied to linux-stable-rc.git,
> branch linux-4.4.y:
>   https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=linux-4.4.y
>   https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/tree/include/linux/fs.h?h=linux-4.4.y&id=7d690c56754ef7be647fbcf7bcdceebd59926b3f#n929
> 
> That is what has been tested above - is that the correct place
> to get your backport of 0cc3b0ec23ce?

I only push out the -rc git tree when I am at a "stopping point" in work
on the stable tree.  If I added this patch earlier today, I have not
pushed out a new -rc.  Please work off of the stable-queue.git tree
instead if you want to always see the latest version of what I have
applied to the queue.

thanks,

greg k-h