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... 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
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.4.137-rc1
Eric Dumazet edumazet@google.com net: metrics: add proper netlink validation
Florian Fainelli f.fainelli@gmail.com net: phy: broadcom: Fix bcm_write_exp()
Eric Dumazet edumazet@google.com rtnetlink: validate attributes in do_setlink()
Dan Carpenter dan.carpenter@oracle.com team: use netdev_features_t instead of u32
Jack Morgenstein jackm@dev.mellanox.co.il net/mlx4: Fix irq-unsafe spinlock usage
Shahed Shaikh shahed.shaikh@cavium.com qed: Fix mask for physical address in ILT entry
Willem de Bruijn willemb@google.com packet: fix reserve calculation
Daniele Palmas dnlplm@gmail.com net: usb: cdc_mbim: add flag FLAG_SEND_ZLP
Eric Dumazet edumazet@google.com net/packet: refine check for priv area size
Cong Wang xiyou.wangcong@gmail.com netdev-FAQ: clarify DaveM's position for stable backports
Wenwen Wang wang6495@umn.edu isdn: eicon: fix a missing-check bug
Willem de Bruijn willemb@google.com ipv4: remove warning in ip_recv_error
Sabrina Dubroca sd@queasysnail.net ip6mr: only set ip6mr_table from setsockopt when ip6mr_new_table succeeds
Govindarajulu Varadarajan gvaradar@cisco.com enic: set DMA mask to 47 bit
Alexey Kodanev alexey.kodanev@oracle.com dccp: don't free ccid2_hc_tx_sock struct in dccp_disconnect()
Julia Lawall Julia.Lawall@lip6.fr bnx2x: use the right constant
Stefan Wahren stefan.wahren@i2se.com brcmfmac: Fix check for ISO3166 code
Dave Airlie airlied@redhat.com drm: set FMODE_UNSIGNED_OFFSET for drm files
Amir Goldstein amir73il@gmail.com xfs: fix incorrect log_flushed on fsync
Nathan Chancellor natechancellor@gmail.com kconfig: Avoid format overflow warning from GCC 8.1
Linus Torvalds torvalds@linux-foundation.org mmap: relax file size limit for regular files
Linus Torvalds torvalds@linux-foundation.org mmap: introduce sane default mmap limits
Chris Chiu chiu@endlessm.com tpm: self test failure should not cause suspend to fail
Enric Balletbo i Serra enric.balletbo@collabora.com tpm: do not suspend/resume if power stays on
-------------
Diffstat:
Documentation/networking/netdev-FAQ.txt | 9 ++++++ Makefile | 4 +-- drivers/char/tpm/tpm-chip.c | 13 +++++++++ drivers/char/tpm/tpm-interface.c | 7 +++++ drivers/char/tpm/tpm.h | 1 + drivers/gpu/drm/drm_fops.c | 1 + drivers/isdn/hardware/eicon/diva.c | 22 ++++++++++----- drivers/isdn/hardware/eicon/diva.h | 5 ++-- drivers/isdn/hardware/eicon/divasmain.c | 18 +++++++----- drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 2 +- drivers/net/ethernet/cisco/enic/enic_main.c | 8 +++--- drivers/net/ethernet/mellanox/mlx4/qp.c | 4 +-- drivers/net/ethernet/qlogic/qed/qed_cxt.c | 2 +- drivers/net/phy/bcm-cygnus.c | 6 ++-- drivers/net/phy/bcm-phy-lib.h | 7 +++++ drivers/net/phy/bcm7xxx.c | 4 +-- drivers/net/team/team.c | 3 +- drivers/net/usb/cdc_mbim.c | 2 +- drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 2 +- fs/xfs/xfs_log.c | 7 ----- mm/mmap.c | 32 ++++++++++++++++++++++ net/core/rtnetlink.c | 8 +++--- net/dccp/proto.c | 2 -- net/ipv4/fib_semantics.c | 2 ++ net/ipv4/ip_sockglue.c | 2 -- net/ipv6/ip6mr.c | 3 +- net/packet/af_packet.c | 4 +-- scripts/kconfig/confdata.c | 2 +- 28 files changed, 129 insertions(+), 53 deletions(-)
On Tue, Jun 12, 2018 at 06:51:44PM +0200, Greg Kroah-Hartman 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... 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
Merged, compiled with -Werror, and installed on my Pixel 2 XL and OnePlus 5.
No initial issues noticed in dmesg or general usage.
Thanks! Nathan
On Tue, Jun 12, 2018 at 11:17:25AM -0700, Nathan Chancellor wrote:
On Tue, Jun 12, 2018 at 06:51:44PM +0200, Greg Kroah-Hartman 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... 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
Merged, compiled with -Werror, and installed on my Pixel 2 XL and OnePlus 5.
No initial issues noticed in dmesg or general usage.
Thanks for testing this, and the 3.18.y tree.
greg k-h
On 06/12/2018 10:51 AM, Greg Kroah-Hartman 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... 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
Compiled and booted on my test system. No dmesg regressions.
thanks, -- Shuah
stable-rc/linux-4.4.y boot: 87 boots: 1 failed, 85 passed with 1 conflict (v4.4.136-25-g678437d36d4e)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.1... Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.136-25-g...
Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.136-25-g678437d36d4e Git Commit: 678437d36d4e14a029309f1c282802ce47fda36a Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 44 unique boards, 20 SoC families, 15 builds out of 178
Boot Regressions Detected:
x86:
x86_64_defconfig: qemu: lab-baylibre: failing since 1 day (last pass: v4.4.135-36-ge757a1c0b2b0 - first fail: v4.4.136)
Boot Failure Detected:
arm64:
defconfig synquacer-acpi: 1 failed lab
Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
x86:
x86_64_defconfig: qemu: lab-linaro-lkft: PASS lab-mhart: PASS lab-collabora: PASS lab-baylibre: FAIL
--- For more info write to info@kernelci.org
On 06/12/2018 09:51 AM, Greg Kroah-Hartman 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.
Build results: total: 148 pass: 148 fail: 0 Qemu test results: total: 135 pass: 135 fail: 0
Details are available at http://kerneltests.org/builders/.
Guenter
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-...
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.1...
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... 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
On Wed, Jun 13, 2018 at 05:47:49PM -0300, Rafael Tinoco wrote:
Results from Linaro’s test farm. Regressions detected.
NOTE:
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?
thanks,
greg k-h
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:
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.
thanks,
greg k-h
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:
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.
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:
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
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:
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-...
On the side note, Kernel selftests version upgrade to 4.17.
- Naresh
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:
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-...
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
----- 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-...
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
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-...
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
----- 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-...
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/l... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/t...
That is what has been tested above - is that the correct place to get your backport of 0cc3b0ec23ce?
Regards, Jan
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...
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-...
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/l... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/t...
That is what has been tested above - is that the correct place to get your backport of 0cc3b0ec23ce?
Regards, Jan
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-...
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/l... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/t...
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
-
Greg Kroah-Hartman -
Guenter Roeck -
Jan Stancek -
kernelci.org bot -
Naresh Kamboju -
Nathan Chancellor -
Rafael David Tinoco -
Rafael Tinoco -
Shuah Khan