All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rafael Tinoco <rafael.tinoco@linaro.org>
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, ltp@lists.linux.it,
	Rafael Tinoco <rafael.tinoco@linaro.org>
Subject: Re: [PATCH 4.4 00/24] 4.4.137-stable review
Date: Wed, 13 Jun 2018 22:48:50 -0300	[thread overview]
Message-ID: <CADtBP2DZ0ceTtwaG7AdXV3xa16mQ6nu=gaqUYj7JSOLBdVD8cg@mail.gmail.com> (raw)
In-Reply-To: <CABdQkv9uNjf7ARKBJ-sE_RVruMA5U9bTNo-EL_+7Rv8ZVJGY3w@mail.gmail.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Rafael Tinoco <rafael.tinoco@linaro.org>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 4.4 00/24] 4.4.137-stable review
Date: Wed, 13 Jun 2018 22:48:50 -0300	[thread overview]
Message-ID: <CADtBP2DZ0ceTtwaG7AdXV3xa16mQ6nu=gaqUYj7JSOLBdVD8cg@mail.gmail.com> (raw)
In-Reply-To: <CABdQkv9uNjf7ARKBJ-sE_RVruMA5U9bTNo-EL_+7Rv8ZVJGY3w@mail.gmail.com>

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.

  reply	other threads:[~2018-06-14  1:49 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-12 16:51 [PATCH 4.4 00/24] 4.4.137-stable review Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 01/24] tpm: do not suspend/resume if power stays on Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 02/24] tpm: self test failure should not cause suspend to fail Greg Kroah-Hartman
2018-06-12 16:51   ` Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 03/24] mmap: introduce sane default mmap limits Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 04/24] mmap: relax file size limit for regular files Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 06/24] xfs: fix incorrect log_flushed on fsync Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 07/24] drm: set FMODE_UNSIGNED_OFFSET for drm files Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 08/24] brcmfmac: Fix check for ISO3166 code Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 09/24] bnx2x: use the right constant Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 10/24] dccp: dont free ccid2_hc_tx_sock struct in dccp_disconnect() Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 11/24] enic: set DMA mask to 47 bit Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 12/24] ip6mr: only set ip6mr_table from setsockopt when ip6mr_new_table succeeds Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 13/24] ipv4: remove warning in ip_recv_error Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 14/24] isdn: eicon: fix a missing-check bug Greg Kroah-Hartman
2018-06-12 16:51 ` [PATCH 4.4 15/24] netdev-FAQ: clarify DaveMs position for stable backports Greg Kroah-Hartman
2018-06-12 16:52 ` [PATCH 4.4 16/24] net/packet: refine check for priv area size Greg Kroah-Hartman
2018-06-12 16:52 ` [PATCH 4.4 18/24] packet: fix reserve calculation Greg Kroah-Hartman
2018-06-12 16:52 ` [PATCH 4.4 19/24] qed: Fix mask for physical address in ILT entry Greg Kroah-Hartman
2018-06-12 16:52 ` [PATCH 4.4 20/24] net/mlx4: Fix irq-unsafe spinlock usage Greg Kroah-Hartman
2018-06-12 16:52 ` [PATCH 4.4 21/24] team: use netdev_features_t instead of u32 Greg Kroah-Hartman
2018-06-12 16:52 ` [PATCH 4.4 22/24] rtnetlink: validate attributes in do_setlink() Greg Kroah-Hartman
2018-06-12 16:52 ` [PATCH 4.4 23/24] net: phy: broadcom: Fix bcm_write_exp() Greg Kroah-Hartman
2018-06-12 16:52 ` [PATCH 4.4 24/24] net: metrics: add proper netlink validation Greg Kroah-Hartman
2018-06-19 13:15   ` Ben Hutchings
2018-06-12 18:17 ` [PATCH 4.4 00/24] 4.4.137-stable review Nathan Chancellor
2018-06-12 18:49   ` Greg Kroah-Hartman
2018-06-12 20:59 ` Shuah Khan
2018-06-13 13:48 ` Guenter Roeck
2018-06-13 20:47 ` Rafael Tinoco
2018-06-13 20:52   ` [LTP] Fwd: " Rafael Tinoco
2018-06-13 21:36     ` [LTP] " Rafael Tinoco
2018-06-13 21:00   ` Greg Kroah-Hartman
2018-06-13 21:08     ` Rafael David Tinoco
2018-06-14  1:48       ` Rafael Tinoco [this message]
2018-06-14  1:48         ` [LTP] " Rafael Tinoco
2018-06-14  6:34         ` Greg Kroah-Hartman
2018-06-14  6:34           ` [LTP] " Greg Kroah-Hartman
2018-06-14  8:54           ` Naresh Kamboju
2018-06-14  8:54             ` [LTP] " Naresh Kamboju
2018-06-14  9:01             ` Greg Kroah-Hartman
2018-06-14  9:01               ` [LTP] " Greg Kroah-Hartman
2018-06-14  9:49               ` Jan Stancek
2018-06-14  9:49                 ` Jan Stancek
2018-06-14 10:21                 ` Greg Kroah-Hartman
2018-06-14 10:21                   ` Greg Kroah-Hartman
2018-06-14 10:36                   ` Jan Stancek
2018-06-14 10:36                     ` Jan Stancek
2018-06-14 10:54                     ` Rafael Tinoco
2018-06-14 10:54                       ` Rafael Tinoco
2018-06-14 11:36                     ` Greg Kroah-Hartman
2018-06-14 11:36                       ` Greg Kroah-Hartman

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='CADtBP2DZ0ceTtwaG7AdXV3xa16mQ6nu=gaqUYj7JSOLBdVD8cg@mail.gmail.com' \
    --to=rafael.tinoco@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=ben.hutchings@codethink.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lkft-triage@lists.linaro.org \
    --cc=ltp@lists.linux.it \
    --cc=patches@kernelci.org \
    --cc=shuah@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.