[PATCH 4.4 00/24] 4.4.137-stable review

[PATCH 4.4 00/24] 4.4.137-stable review

[Greg Kroah-Hartman]

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

-------------
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(-)

[PATCH 4.4 01/24] tpm: do not suspend/resume if power stays on

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Enric Balletbo i Serra <enric.balletbo@collabora.com>

commit b5d0ebc99bf5d0801a5ecbe958caa3d68b8eaee8 upstream.

The suspend/resume behavior of the TPM can be controlled by setting
"powered-while-suspended" in the DTS. This is useful for the cases
when hardware does not power-off the TPM.

Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/char/tpm/tpm-chip.c      |   13 +++++++++++++
 drivers/char/tpm/tpm-interface.c |    3 +++
 drivers/char/tpm/tpm.h           |    1 +
 3 files changed, 17 insertions(+)

--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -26,6 +26,7 @@
 #include <linux/spinlock.h>
 #include <linux/freezer.h>
 #include <linux/major.h>
+#include <linux/of.h>
 #include "tpm.h"
 #include "tpm_eventlog.h"
 
@@ -324,8 +325,20 @@ static void tpm1_chip_unregister(struct
  */
 int tpm_chip_register(struct tpm_chip *chip)
 {
+#ifdef CONFIG_OF
+	struct device_node *np;
+#endif
 	int rc;
 
+#ifdef CONFIG_OF
+	np = of_find_node_by_name(NULL, "vtpm");
+	if (np) {
+		if (of_property_read_bool(np, "powered-while-suspended"))
+			chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED;
+	}
+	of_node_put(np);
+#endif
+
 	rc = tpm1_chip_register(chip);
 	if (rc)
 		return rc;
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -931,6 +931,9 @@ int tpm_pm_suspend(struct device *dev)
 	if (chip == NULL)
 		return -ENODEV;
 
+	if (chip->flags & TPM_CHIP_FLAG_ALWAYS_POWERED)
+		return 0;
+
 	if (chip->flags & TPM_CHIP_FLAG_TPM2) {
 		tpm2_shutdown(chip, TPM2_SU_STATE);
 		return 0;
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -168,6 +168,7 @@ struct tpm_vendor_specific {
 enum tpm_chip_flags {
 	TPM_CHIP_FLAG_REGISTERED	= BIT(0),
 	TPM_CHIP_FLAG_TPM2		= BIT(1),
+	TPM_CHIP_FLAG_ALWAYS_POWERED	= BIT(5),
 };
 
 struct tpm_chip {

[PATCH 4.4 02/24] tpm: self test failure should not cause suspend to fail

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Chris Chiu <chiu@endlessm.com>

commit 0803d7befa15cab5717d667a97a66214d2a4c083 upstream.

The Acer Acer Veriton X4110G has a TPM device detected as:
  tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71)

After the first S3 suspend, the following error appears during resume:
  tpm tpm0: A TPM error(38) occurred continue selftest

Any following S3 suspend attempts will now fail with this error:
  tpm tpm0: Error (38) sending savestate before suspend
  PM: Device 00:0b failed to suspend: error 38

Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is
not in the correct state. This indicates that the platform BIOS
is not sending the usual TPM_Startup command during S3 resume.
>From this point onwards, all TPM commands will fail.

The same issue was previously reported on Foxconn 6150BK8MC and
Sony Vaio TX3.

The platform behaviour seems broken here, but we should not break
suspend/resume because of this.

When the unexpected TPM state is encountered, set a flag to skip the
affected TPM_SaveState command on later suspends.

Cc: stable@vger.kernel.org
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23UiQ@mail.gmail.com
Link: https://lkml.org/lkml/2011/3/28/192
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/char/tpm/tpm-interface.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -787,6 +787,10 @@ int tpm_do_selftest(struct tpm_chip *chi
 	loops = jiffies_to_msecs(duration) / delay_msec;
 
 	rc = tpm_continue_selftest(chip);
+	if (rc == TPM_ERR_INVALID_POSTINIT) {
+		chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED;
+		dev_info(&chip->dev, "TPM not ready (%d)\n", rc);
+	}
 	/* This may fail if there was no TPM driver during a suspend/resume
 	 * cycle; some may return 10 (BAD_ORDINAL), others 28 (FAILEDSELFTEST)
 	 */

[PATCH 4.4 02/24] tpm: self test failure should not cause suspend to fail

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Chris Chiu <chiu@endlessm.com>

commit 0803d7befa15cab5717d667a97a66214d2a4c083 upstream.

The Acer Acer Veriton X4110G has a TPM device detected as:
  tpm_tis 00:0b: 1.2 TPM (device-id 0xFE, rev-id 71)

After the first S3 suspend, the following error appears during resume:
  tpm tpm0: A TPM error(38) occurred continue selftest

Any following S3 suspend attempts will now fail with this error:
  tpm tpm0: Error (38) sending savestate before suspend
  PM: Device 00:0b failed to suspend: error 38

Error 38 is TPM_ERR_INVALID_POSTINIT which means the TPM is
not in the correct state. This indicates that the platform BIOS
is not sending the usual TPM_Startup command during S3 resume.
>>From this point onwards, all TPM commands will fail.

The same issue was previously reported on Foxconn 6150BK8MC and
Sony Vaio TX3.

The platform behaviour seems broken here, but we should not break
suspend/resume because of this.

When the unexpected TPM state is encountered, set a flag to skip the
affected TPM_SaveState command on later suspends.

Cc: stable@vger.kernel.org
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Daniel Drake <drake@endlessm.com>
Link: http://lkml.kernel.org/r/CAB4CAwfSCvj1cudi+MWaB5g2Z67d9DwY1o475YOZD64ma23UiQ@mail.gmail.com
Link: https://lkml.org/lkml/2011/3/28/192
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591031
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/char/tpm/tpm-interface.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -787,6 +787,10 @@ int tpm_do_selftest(struct tpm_chip *chi
 	loops = jiffies_to_msecs(duration) / delay_msec;
 
 	rc = tpm_continue_selftest(chip);
+	if (rc == TPM_ERR_INVALID_POSTINIT) {
+		chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED;
+		dev_info(&chip->dev, "TPM not ready (%d)\n", rc);
+	}
 	/* This may fail if there was no TPM driver during a suspend/resume
 	 * cycle; some may return 10 (BAD_ORDINAL), others 28 (FAILEDSELFTEST)
 	 */

[PATCH 4.4 03/24] mmap: introduce sane default mmap limits

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Linus Torvalds <torvalds@linux-foundation.org>

commit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.

The internal VM "mmap()" interfaces are based on the mmap target doing
everything using page indexes rather than byte offsets, because
traditionally (ie 32-bit) we had the situation that the byte offset
didn't fit in a register.  So while the mmap virtual address was limited
by the word size of the architecture, the backing store was not.

So we're basically passing "pgoff" around as a page index, in order to
be able to describe backing store locations that are much bigger than
the word size (think files larger than 4GB etc).

But while this all makes a ton of sense conceptually, we've been dogged
by various drivers that don't really understand this, and internally
work with byte offsets, and then try to work with the page index by
turning it into a byte offset with "pgoff << PAGE_SHIFT".

Which obviously can overflow.

Adding the size of the mapping to it to get the byte offset of the end
of the backing store just exacerbates the problem, and if you then use
this overflow-prone value to check various limits of your device driver
mmap capability, you're just setting yourself up for problems.

The correct thing for drivers to do is to do their limit math in page
indices, the way the interface is designed.  Because the generic mmap
code _does_ test that the index doesn't overflow, since that's what the
mmap code really cares about.

HOWEVER.

Finding and fixing various random drivers is a sisyphean task, so let's
just see if we can just make the core mmap() code do the limiting for
us.  Realistically, the only "big" backing stores we need to care about
are regular files and block devices, both of which are known to do this
properly, and which have nice well-defined limits for how much data they
can access.

So let's special-case just those two known cases, and then limit other
random mmap users to a backing store that still fits in "unsigned long".
Realistically, that's not much of a limit at all on 64-bit, and on
32-bit architectures the only worry might be the GPU drivers, which can
have big physical address spaces.

To make it possible for drivers like that to say that they are 64-bit
clean, this patch does repurpose the "FMODE_UNSIGNED_OFFSET" bit in the
file flags to allow drivers to mark their file descriptors as safe in
the full 64-bit mmap address space.

[ The timing for doing this is less than optimal, and this should really
  go in a merge window. But realistically, this needs wide testing more
  than it needs anything else, and being main-line is the only way to do
  that.

  So the earlier the better, even if it's outside the proper development
  cycle        - Linus ]

Cc: Kees Cook <keescook@chromium.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/mmap.c |   32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1275,6 +1275,35 @@ static inline int mlock_future_check(str
 	return 0;
 }
 
+static inline u64 file_mmap_size_max(struct file *file, struct inode *inode)
+{
+	if (S_ISREG(inode->i_mode))
+		return inode->i_sb->s_maxbytes;
+
+	if (S_ISBLK(inode->i_mode))
+		return MAX_LFS_FILESIZE;
+
+	/* Special "we do even unsigned file positions" case */
+	if (file->f_mode & FMODE_UNSIGNED_OFFSET)
+		return 0;
+
+	/* Yes, random drivers might want more. But I'm tired of buggy drivers */
+	return ULONG_MAX;
+}
+
+static inline bool file_mmap_ok(struct file *file, struct inode *inode,
+				unsigned long pgoff, unsigned long len)
+{
+	u64 maxsize = file_mmap_size_max(file, inode);
+
+	if (maxsize && len > maxsize)
+		return false;
+	maxsize -= len;
+	if (pgoff > maxsize >> PAGE_SHIFT)
+		return false;
+	return true;
+}
+
 /*
  * The caller must hold down_write(&current->mm->mmap_sem).
  */
@@ -1340,6 +1369,9 @@ unsigned long do_mmap(struct file *file,
 	if (file) {
 		struct inode *inode = file_inode(file);
 
+		if (!file_mmap_ok(file, inode, pgoff, len))
+			return -EOVERFLOW;
+
 		switch (flags & MAP_TYPE) {
 		case MAP_SHARED:
 			if ((prot&PROT_WRITE) && !(file->f_mode&FMODE_WRITE))

[PATCH 4.4 04/24] mmap: relax file size limit for regular files

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Linus Torvalds <torvalds@linux-foundation.org>

commit 423913ad4ae5b3e8fb8983f70969fb522261ba26 upstream.

Commit be83bbf80682 ("mmap: introduce sane default mmap limits") was
introduced to catch problems in various ad-hoc character device drivers
doing mmap and getting the size limits wrong.  In the process, it used
"known good" limits for the normal cases of mapping regular files and
block device drivers.

It turns out that the "s_maxbytes" limit was less "known good" than I
thought.  In particular, /proc doesn't set it, but exposes one regular
file to mmap: /proc/vmcore.  As a result, that file got limited to the
default MAX_INT s_maxbytes value.

This went unnoticed for a while, because apparently the only thing that
needs it is the s390 kernel zfcpdump, but there might be other tools
that use this too.

Vasily suggested just changing s_maxbytes for all of /proc, which isn't
wrong, but makes me nervous at this stage.  So instead, just make the
new mmap limit always be MAX_LFS_FILESIZE for regular files, which won't
affect anything else.  It wasn't the regular file case I was worried
about.

I'd really prefer for maxsize to have been per-inode, but that is not
how things are today.

Fixes: be83bbf80682 ("mmap: introduce sane default mmap limits")
Reported-by: Vasily Gorbik <gor@linux.ibm.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/mmap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1278,7 +1278,7 @@ static inline int mlock_future_check(str
 static inline u64 file_mmap_size_max(struct file *file, struct inode *inode)
 {
 	if (S_ISREG(inode->i_mode))
-		return inode->i_sb->s_maxbytes;
+		return MAX_LFS_FILESIZE;
 
 	if (S_ISBLK(inode->i_mode))
 		return MAX_LFS_FILESIZE;

[PATCH 4.4 06/24] xfs: fix incorrect log_flushed on fsync

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Amir Goldstein <amir73il@gmail.com>

commit 47c7d0b19502583120c3f396c7559e7a77288a68 upstream.

When calling into _xfs_log_force{,_lsn}() with a pointer
to log_flushed variable, log_flushed will be set to 1 if:
1. xlog_sync() is called to flush the active log buffer
AND/OR
2. xlog_wait() is called to wait on a syncing log buffers

xfs_file_fsync() checks the value of log_flushed after
_xfs_log_force_lsn() call to optimize away an explicit
PREFLUSH request to the data block device after writing
out all the file's pages to disk.

This optimization is incorrect in the following sequence of events:

 Task A                    Task B
 -------------------------------------------------------
 xfs_file_fsync()
   _xfs_log_force_lsn()
     xlog_sync()
        [submit PREFLUSH]
                           xfs_file_fsync()
                             file_write_and_wait_range()
                               [submit WRITE X]
                               [endio  WRITE X]
                             _xfs_log_force_lsn()
                               xlog_wait()
        [endio  PREFLUSH]

The write X is not guarantied to be on persistent storage
when PREFLUSH request in completed, because write A was submitted
after the PREFLUSH request, but xfs_file_fsync() of task A will
be notified of log_flushed=1 and will skip explicit flush.

If the system crashes after fsync of task A, write X may not be
present on disk after reboot.

This bug was discovered and demonstrated using Josef Bacik's
dm-log-writes target, which can be used to record block io operations
and then replay a subset of these operations onto the target device.
The test goes something like this:
- Use fsx to execute ops of a file and record ops on log device
- Every now and then fsync the file, store md5 of file and mark
  the location in the log
- Then replay log onto device for each mark, mount fs and compare
  md5 of file to stored value

Cc: Christoph Hellwig <hch@lst.de>
Cc: Josef Bacik <jbacik@fb.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/xfs/xfs_log.c |    7 -------
 1 file changed, 7 deletions(-)

--- a/fs/xfs/xfs_log.c
+++ b/fs/xfs/xfs_log.c
@@ -3323,8 +3323,6 @@ maybe_sleep:
 		 */
 		if (iclog->ic_state & XLOG_STATE_IOERROR)
 			return -EIO;
-		if (log_flushed)
-			*log_flushed = 1;
 	} else {
 
 no_sleep:
@@ -3432,8 +3430,6 @@ try_again:
 
 				xlog_wait(&iclog->ic_prev->ic_write_wait,
 							&log->l_icloglock);
-				if (log_flushed)
-					*log_flushed = 1;
 				already_slept = 1;
 				goto try_again;
 			}
@@ -3467,9 +3463,6 @@ try_again:
 			 */
 			if (iclog->ic_state & XLOG_STATE_IOERROR)
 				return -EIO;
-
-			if (log_flushed)
-				*log_flushed = 1;
 		} else {		/* just return */
 			spin_unlock(&log->l_icloglock);
 		}

[PATCH 4.4 07/24] drm: set FMODE_UNSIGNED_OFFSET for drm files

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Dave Airlie <airlied@redhat.com>

commit 76ef6b28ea4f81c3d511866a9b31392caa833126 upstream.

Since we have the ttm and gem vma managers using a subset
of the file address space for objects, and these start at
0x100000000 they will overflow the new mmap checks.

I've checked all the mmap routines I could see for any
bad behaviour but overall most people use GEM/TTM VMA
managers even the legacy drivers have a hashtable.

Reported-and-Tested-by: Arthur Marsh (amarsh04 on #radeon)
Fixes: be83bbf8068 (mmap: introduce sane default mmap limits)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/drm_fops.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -209,6 +209,7 @@ static int drm_open_helper(struct file *
 		return -ENOMEM;
 
 	filp->private_data = priv;
+	filp->f_mode |= FMODE_UNSIGNED_OFFSET;
 	priv->filp = filp;
 	priv->uid = current_euid();
 	priv->pid = get_pid(task_pid(current));

[PATCH 4.4 08/24] brcmfmac: Fix check for ISO3166 code

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Stefan Wahren <stefan.wahren@i2se.com>

commit 9b9322db5c5a1917a66c71fe47c3848a9a31227e upstream.

The commit "regulatory: add NUL to request alpha2" increases the length of
alpha2 to 3. This causes a regression on brcmfmac, because
brcmf_cfg80211_reg_notifier() expect valid ISO3166 codes in the complete
array. So fix this accordingly.

Fixes: 657308f73e67 ("regulatory: add NUL to request alpha2")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
[bwh: Backported to 4.4: adjust filename]
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c
@@ -6167,7 +6167,7 @@ static void brcmf_cfg80211_reg_notifier(
 		  req->alpha2[0], req->alpha2[1]);
 
 	/* ignore non-ISO3166 country codes */
-	for (i = 0; i < sizeof(req->alpha2); i++)
+	for (i = 0; i < 2; i++)
 		if (req->alpha2[i] < 'A' || req->alpha2[i] > 'Z') {
 			brcmf_err("not a ISO3166 code\n");
 			return;

[PATCH 4.4 09/24] bnx2x: use the right constant

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Julia Lawall <Julia.Lawall@lip6.fr>

[ Upstream commit dd612f18a49b63af8b3a5f572d999bdb197385bc ]

Nearby code that also tests port suggests that the P0 constant should be
used when port is zero.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@@
expression e,e1;
@@

* e ? e1 : e1
// </smpl>

Fixes: 6c3218c6f7e5 ("bnx2x: Adjust ETS to 578xx")
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -594,7 +594,7 @@ static void bnx2x_ets_e3b0_nig_disabled(
 	 * slots for the highest priority.
 	 */
 	REG_WR(bp, (port) ? NIG_REG_P1_TX_ARB_NUM_STRICT_ARB_SLOTS :
-		   NIG_REG_P1_TX_ARB_NUM_STRICT_ARB_SLOTS, 0x100);
+		   NIG_REG_P0_TX_ARB_NUM_STRICT_ARB_SLOTS, 0x100);
 	/* Mapping between the CREDIT_WEIGHT registers and actual client
 	 * numbers
 	 */

[PATCH 4.4 10/24] dccp: dont free ccid2_hc_tx_sock struct in dccp_disconnect()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Alexey Kodanev <alexey.kodanev@oracle.com>

[ Upstream commit 2677d20677314101293e6da0094ede7b5526d2b1 ]

Syzbot reported the use-after-free in timer_is_static_object() [1].

This can happen because the structure for the rto timer (ccid2_hc_tx_sock)
is removed in dccp_disconnect(), and ccid2_hc_tx_rto_expire() can be
called after that.

The report [1] is similar to the one in commit 120e9dabaf55 ("dccp:
defer ccid_hc_tx_delete() at dismantle time"). And the fix is the same,
delay freeing ccid2_hc_tx_sock structure, so that it is freed in
dccp_sk_destruct().

[1]

==================================================================
BUG: KASAN: use-after-free in timer_is_static_object+0x80/0x90
kernel/time/timer.c:607
Read of size 8 at addr ffff8801bebb5118 by task syz-executor2/25299

CPU: 1 PID: 25299 Comm: syz-executor2 Not tainted 4.17.0-rc5+ #54
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  <IRQ>
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
  print_address_description+0x6c/0x20b mm/kasan/report.c:256
  kasan_report_error mm/kasan/report.c:354 [inline]
  kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
  timer_is_static_object+0x80/0x90 kernel/time/timer.c:607
  debug_object_activate+0x2d9/0x670 lib/debugobjects.c:508
  debug_timer_activate kernel/time/timer.c:709 [inline]
  debug_activate kernel/time/timer.c:764 [inline]
  __mod_timer kernel/time/timer.c:1041 [inline]
  mod_timer+0x4d3/0x13b0 kernel/time/timer.c:1102
  sk_reset_timer+0x22/0x60 net/core/sock.c:2742
  ccid2_hc_tx_rto_expire+0x587/0x680 net/dccp/ccids/ccid2.c:147
  call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
  expire_timers kernel/time/timer.c:1363 [inline]
  __run_timers+0x79e/0xc50 kernel/time/timer.c:1666
  run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
  invoke_softirq kernel/softirq.c:365 [inline]
  irq_exit+0x1d1/0x200 kernel/softirq.c:405
  exiting_irq arch/x86/include/asm/apic.h:525 [inline]
  smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
  </IRQ>
...
Allocated by task 25374:
  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
  set_track mm/kasan/kasan.c:460 [inline]
  kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
  ccid_new+0x25b/0x3e0 net/dccp/ccid.c:151
  dccp_hdlr_ccid+0x27/0x150 net/dccp/feat.c:44
  __dccp_feat_activate+0x184/0x270 net/dccp/feat.c:344
  dccp_feat_activate_values+0x3a7/0x819 net/dccp/feat.c:1538
  dccp_create_openreq_child+0x472/0x610 net/dccp/minisocks.c:128
  dccp_v4_request_recv_sock+0x12c/0xca0 net/dccp/ipv4.c:408
  dccp_v6_request_recv_sock+0x125d/0x1f10 net/dccp/ipv6.c:415
  dccp_check_req+0x455/0x6a0 net/dccp/minisocks.c:197
  dccp_v4_rcv+0x7b8/0x1f3f net/dccp/ipv4.c:841
  ip_local_deliver_finish+0x2e3/0xd80 net/ipv4/ip_input.c:215
  NF_HOOK include/linux/netfilter.h:288 [inline]
  ip_local_deliver+0x1e1/0x720 net/ipv4/ip_input.c:256
  dst_input include/net/dst.h:450 [inline]
  ip_rcv_finish+0x81b/0x2200 net/ipv4/ip_input.c:396
  NF_HOOK include/linux/netfilter.h:288 [inline]
  ip_rcv+0xb70/0x143d net/ipv4/ip_input.c:492
  __netif_receive_skb_core+0x26f5/0x3630 net/core/dev.c:4592
  __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4657
  process_backlog+0x219/0x760 net/core/dev.c:5337
  napi_poll net/core/dev.c:5735 [inline]
  net_rx_action+0x7b7/0x1930 net/core/dev.c:5801
  __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285

Freed by task 25374:
  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
  set_track mm/kasan/kasan.c:460 [inline]
  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
  __cache_free mm/slab.c:3498 [inline]
  kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
  ccid_hc_tx_delete+0xc3/0x100 net/dccp/ccid.c:190
  dccp_disconnect+0x130/0xc66 net/dccp/proto.c:286
  dccp_close+0x3bc/0xe60 net/dccp/proto.c:1045
  inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
  inet6_release+0x50/0x70 net/ipv6/af_inet6.c:460
  sock_release+0x96/0x1b0 net/socket.c:594
  sock_close+0x16/0x20 net/socket.c:1149
  __fput+0x34d/0x890 fs/file_table.c:209
  ____fput+0x15/0x20 fs/file_table.c:243
  task_work_run+0x1e4/0x290 kernel/task_work.c:113
  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
  exit_to_usermode_loop+0x2bd/0x310 arch/x86/entry/common.c:166
  prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
  syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
  do_syscall_64+0x6ac/0x800 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at ffff8801bebb4cc0
  which belongs to the cache ccid2_hc_tx_sock of size 1240
The buggy address is located 1112 bytes inside of
  1240-byte region [ffff8801bebb4cc0, ffff8801bebb5198)
The buggy address belongs to the page:
page:ffffea0006faed00 count:1 mapcount:0 mapping:ffff8801bebb41c0
index:0xffff8801bebb5240 compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffff8801bebb41c0 ffff8801bebb5240 0000000100000003
raw: ffff8801cdba3138 ffffea0007634120 ffff8801cdbaab40 0000000000000000
page dumped because: kasan: bad access detected
...
==================================================================

Reported-by: syzbot+5d47e9ec91a6f15dbd6f@syzkaller.appspotmail.com
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/dccp/proto.c |    2 --
 1 file changed, 2 deletions(-)

--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -280,9 +280,7 @@ int dccp_disconnect(struct sock *sk, int
 
 	dccp_clear_xmit_timers(sk);
 	ccid_hc_rx_delete(dp->dccps_hc_rx_ccid, sk);
-	ccid_hc_tx_delete(dp->dccps_hc_tx_ccid, sk);
 	dp->dccps_hc_rx_ccid = NULL;
-	dp->dccps_hc_tx_ccid = NULL;
 
 	__skb_queue_purge(&sk->sk_receive_queue);
 	__skb_queue_purge(&sk->sk_write_queue);

[PATCH 4.4 11/24] enic: set DMA mask to 47 bit

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Govindarajulu Varadarajan <gvaradar@cisco.com>

[ Upstream commit 322eaa06d55ebc1402a4a8d140945cff536638b4 ]

In commit 624dbf55a359b ("driver/net: enic: Try DMA 64 first, then
failover to DMA") DMA mask was changed from 40 bits to 64 bits.
Hardware actually supports only 47 bits.

Fixes: 624dbf55a359b ("driver/net: enic: Try DMA 64 first, then failover to DMA")
Signed-off-by: Govindarajulu Varadarajan <gvaradar@cisco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/cisco/enic/enic_main.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -2543,11 +2543,11 @@ static int enic_probe(struct pci_dev *pd
 	pci_set_master(pdev);
 
 	/* Query PCI controller on system for DMA addressing
-	 * limitation for the device.  Try 64-bit first, and
+	 * limitation for the device.  Try 47-bit first, and
 	 * fail to 32-bit.
 	 */
 
-	err = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+	err = pci_set_dma_mask(pdev, DMA_BIT_MASK(47));
 	if (err) {
 		err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
 		if (err) {
@@ -2561,10 +2561,10 @@ static int enic_probe(struct pci_dev *pd
 			goto err_out_release_regions;
 		}
 	} else {
-		err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
+		err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(47));
 		if (err) {
 			dev_err(dev, "Unable to obtain %u-bit DMA "
-				"for consistent allocations, aborting\n", 64);
+				"for consistent allocations, aborting\n", 47);
 			goto err_out_release_regions;
 		}
 		using_dac = 1;

[PATCH 4.4 12/24] ip6mr: only set ip6mr_table from setsockopt when ip6mr_new_table succeeds

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Sabrina Dubroca <sd@queasysnail.net>

[ Upstream commit 848235edb5c93ed086700584c8ff64f6d7fc778d ]

Currently, raw6_sk(sk)->ip6mr_table is set unconditionally during
ip6_mroute_setsockopt(MRT6_TABLE). A subsequent attempt at the same
setsockopt will fail with -ENOENT, since we haven't actually created
that table.

A similar fix for ipv4 was included in commit 5e1859fbcc3c ("ipv4: ipmr:
various fixes and cleanups").

Fixes: d1db275dd3f6 ("ipv6: ip6mr: support multiple tables")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv6/ip6mr.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1787,7 +1787,8 @@ int ip6_mroute_setsockopt(struct sock *s
 		ret = 0;
 		if (!ip6mr_new_table(net, v))
 			ret = -ENOMEM;
-		raw6_sk(sk)->ip6mr_table = v;
+		else
+			raw6_sk(sk)->ip6mr_table = v;
 		rtnl_unlock();
 		return ret;
 	}

[PATCH 4.4 13/24] ipv4: remove warning in ip_recv_error

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Willem de Bruijn <willemb@google.com>

[ Upstream commit 730c54d59403658a62af6517338fa8d4922c1b28 ]

A precondition check in ip_recv_error triggered on an otherwise benign
race. Remove the warning.

The warning triggers when passing an ipv6 socket to this ipv4 error
handling function. RaceFuzzer was able to trigger it due to a race
in setsockopt IPV6_ADDRFORM.

  ---
  CPU0
    do_ipv6_setsockopt
      sk->sk_socket->ops = &inet_dgram_ops;

  ---
  CPU1
    sk->sk_prot->recvmsg
      udp_recvmsg
        ip_recv_error
          WARN_ON_ONCE(sk->sk_family == AF_INET6);

  ---
  CPU0
    do_ipv6_setsockopt
      sk->sk_family = PF_INET;

This socket option converts a v6 socket that is connected to a v4 peer
to an v4 socket. It updates the socket on the fly, changing fields in
sk as well as other structs. This is inherently non-atomic. It races
with the lockless udp_recvmsg path.

No other code makes an assumption that these fields are updated
atomically. It is benign here, too, as ip_recv_error cares only about
the protocol of the skbs enqueued on the error queue, for which
sk_family is not a precise predictor (thanks to another isue with
IPV6_ADDRFORM).

Link: http://lkml.kernel.org/r/20180518120826.GA19515@dragonet.kaist.ac.kr
Fixes: 7ce875e5ecb8 ("ipv4: warn once on passing AF_INET6 socket to ip_recv_error")
Reported-by: DaeRyong Jeong <threeearcat@gmail.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv4/ip_sockglue.c |    2 --
 1 file changed, 2 deletions(-)

--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -493,8 +493,6 @@ int ip_recv_error(struct sock *sk, struc
 	int err;
 	int copied;
 
-	WARN_ON_ONCE(sk->sk_family == AF_INET6);
-
 	err = -EAGAIN;
 	skb = sock_dequeue_err_skb(sk);
 	if (!skb)

[PATCH 4.4 14/24] isdn: eicon: fix a missing-check bug

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Wenwen Wang <wang6495@umn.edu>

[ Upstream commit 6009d1fe6ba3bb2dab55921da60465329cc1cd89 ]

In divasmain.c, the function divas_write() firstly invokes the function
diva_xdi_open_adapter() to open the adapter that matches with the adapter
number provided by the user, and then invokes the function diva_xdi_write()
to perform the write operation using the matched adapter. The two functions
diva_xdi_open_adapter() and diva_xdi_write() are located in diva.c.

In diva_xdi_open_adapter(), the user command is copied to the object 'msg'
from the userspace pointer 'src' through the function pointer 'cp_fn',
which eventually calls copy_from_user() to do the copy. Then, the adapter
number 'msg.adapter' is used to find out a matched adapter from the
'adapter_queue'. A matched adapter will be returned if it is found.
Otherwise, NULL is returned to indicate the failure of the verification on
the adapter number.

As mentioned above, if a matched adapter is returned, the function
diva_xdi_write() is invoked to perform the write operation. In this
function, the user command is copied once again from the userspace pointer
'src', which is the same as the 'src' pointer in diva_xdi_open_adapter() as
both of them are from the 'buf' pointer in divas_write(). Similarly, the
copy is achieved through the function pointer 'cp_fn', which finally calls
copy_from_user(). After the successful copy, the corresponding command
processing handler of the matched adapter is invoked to perform the write
operation.

It is obvious that there are two copies here from userspace, one is in
diva_xdi_open_adapter(), and one is in diva_xdi_write(). Plus, both of
these two copies share the same source userspace pointer, i.e., the 'buf'
pointer in divas_write(). Given that a malicious userspace process can race
to change the content pointed by the 'buf' pointer, this can pose potential
security issues. For example, in the first copy, the user provides a valid
adapter number to pass the verification process and a valid adapter can be
found. Then the user can modify the adapter number to an invalid number.
This way, the user can bypass the verification process of the adapter
number and inject inconsistent data.

This patch reuses the data copied in
diva_xdi_open_adapter() and passes it to diva_xdi_write(). This way, the
above issues can be avoided.

Signed-off-by: Wenwen Wang <wang6495@umn.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/isdn/hardware/eicon/diva.c      |   22 +++++++++++++++-------
 drivers/isdn/hardware/eicon/diva.h      |    5 +++--
 drivers/isdn/hardware/eicon/divasmain.c |   18 +++++++++++-------
 3 files changed, 29 insertions(+), 16 deletions(-)

--- a/drivers/isdn/hardware/eicon/diva.c
+++ b/drivers/isdn/hardware/eicon/diva.c
@@ -387,10 +387,10 @@ void divasa_xdi_driver_unload(void)
 **  Receive and process command from user mode utility
 */
 void *diva_xdi_open_adapter(void *os_handle, const void __user *src,
-			    int length,
+			    int length, void *mptr,
 			    divas_xdi_copy_from_user_fn_t cp_fn)
 {
-	diva_xdi_um_cfg_cmd_t msg;
+	diva_xdi_um_cfg_cmd_t *msg = (diva_xdi_um_cfg_cmd_t *)mptr;
 	diva_os_xdi_adapter_t *a = NULL;
 	diva_os_spin_lock_magic_t old_irql;
 	struct list_head *tmp;
@@ -400,21 +400,21 @@ void *diva_xdi_open_adapter(void *os_han
 			 length, sizeof(diva_xdi_um_cfg_cmd_t)))
 			return NULL;
 	}
-	if ((*cp_fn) (os_handle, &msg, src, sizeof(msg)) <= 0) {
+	if ((*cp_fn) (os_handle, msg, src, sizeof(*msg)) <= 0) {
 		DBG_ERR(("A: A(?) open, write error"))
 			return NULL;
 	}
 	diva_os_enter_spin_lock(&adapter_lock, &old_irql, "open_adapter");
 	list_for_each(tmp, &adapter_queue) {
 		a = list_entry(tmp, diva_os_xdi_adapter_t, link);
-		if (a->controller == (int)msg.adapter)
+		if (a->controller == (int)msg->adapter)
 			break;
 		a = NULL;
 	}
 	diva_os_leave_spin_lock(&adapter_lock, &old_irql, "open_adapter");
 
 	if (!a) {
-		DBG_ERR(("A: A(%d) open, adapter not found", msg.adapter))
+		DBG_ERR(("A: A(%d) open, adapter not found", msg->adapter))
 			}
 
 	return (a);
@@ -436,8 +436,10 @@ void diva_xdi_close_adapter(void *adapte
 
 int
 diva_xdi_write(void *adapter, void *os_handle, const void __user *src,
-	       int length, divas_xdi_copy_from_user_fn_t cp_fn)
+	       int length, void *mptr,
+	       divas_xdi_copy_from_user_fn_t cp_fn)
 {
+	diva_xdi_um_cfg_cmd_t *msg = (diva_xdi_um_cfg_cmd_t *)mptr;
 	diva_os_xdi_adapter_t *a = (diva_os_xdi_adapter_t *) adapter;
 	void *data;
 
@@ -458,7 +460,13 @@ diva_xdi_write(void *adapter, void *os_h
 			return (-2);
 	}
 
-	length = (*cp_fn) (os_handle, data, src, length);
+	if (msg) {
+		*(diva_xdi_um_cfg_cmd_t *)data = *msg;
+		length = (*cp_fn) (os_handle, (char *)data + sizeof(*msg),
+				   src + sizeof(*msg), length - sizeof(*msg));
+	} else {
+		length = (*cp_fn) (os_handle, data, src, length);
+	}
 	if (length > 0) {
 		if ((*(a->interface.cmd_proc))
 		    (a, (diva_xdi_um_cfg_cmd_t *) data, length)) {
--- a/drivers/isdn/hardware/eicon/diva.h
+++ b/drivers/isdn/hardware/eicon/diva.h
@@ -19,10 +19,11 @@ int diva_xdi_read(void *adapter, void *o
 		  int max_length, divas_xdi_copy_to_user_fn_t cp_fn);
 
 int diva_xdi_write(void *adapter, void *os_handle, const void __user *src,
-		   int length, divas_xdi_copy_from_user_fn_t cp_fn);
+		   int length, void *msg,
+		   divas_xdi_copy_from_user_fn_t cp_fn);
 
 void *diva_xdi_open_adapter(void *os_handle, const void __user *src,
-			    int length,
+			    int length, void *msg,
 			    divas_xdi_copy_from_user_fn_t cp_fn);
 
 void diva_xdi_close_adapter(void *adapter, void *os_handle);
--- a/drivers/isdn/hardware/eicon/divasmain.c
+++ b/drivers/isdn/hardware/eicon/divasmain.c
@@ -591,19 +591,22 @@ static int divas_release(struct inode *i
 static ssize_t divas_write(struct file *file, const char __user *buf,
 			   size_t count, loff_t *ppos)
 {
+	diva_xdi_um_cfg_cmd_t msg;
 	int ret = -EINVAL;
 
 	if (!file->private_data) {
 		file->private_data = diva_xdi_open_adapter(file, buf,
-							   count,
+							   count, &msg,
 							   xdi_copy_from_user);
-	}
-	if (!file->private_data) {
-		return (-ENODEV);
+		if (!file->private_data)
+			return (-ENODEV);
+		ret = diva_xdi_write(file->private_data, file,
+				     buf, count, &msg, xdi_copy_from_user);
+	} else {
+		ret = diva_xdi_write(file->private_data, file,
+				     buf, count, NULL, xdi_copy_from_user);
 	}
 
-	ret = diva_xdi_write(file->private_data, file,
-			     buf, count, xdi_copy_from_user);
 	switch (ret) {
 	case -1:		/* Message should be removed from rx mailbox first */
 		ret = -EBUSY;
@@ -622,11 +625,12 @@ static ssize_t divas_write(struct file *
 static ssize_t divas_read(struct file *file, char __user *buf,
 			  size_t count, loff_t *ppos)
 {
+	diva_xdi_um_cfg_cmd_t msg;
 	int ret = -EINVAL;
 
 	if (!file->private_data) {
 		file->private_data = diva_xdi_open_adapter(file, buf,
-							   count,
+							   count, &msg,
 							   xdi_copy_from_user);
 	}
 	if (!file->private_data) {

[PATCH 4.4 15/24] netdev-FAQ: clarify DaveMs position for stable backports

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Cong Wang <xiyou.wangcong@gmail.com>

[ Upstream commit 75d4e704fa8d2cf33ff295e5b441317603d7f9fd ]

Per discussion with David at netconf 2018, let's clarify
DaveM's position of handling stable backports in netdev-FAQ.

This is important for people relying on upstream -stable
releases.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 Documentation/networking/netdev-FAQ.txt |    9 +++++++++
 1 file changed, 9 insertions(+)

--- a/Documentation/networking/netdev-FAQ.txt
+++ b/Documentation/networking/netdev-FAQ.txt
@@ -168,6 +168,15 @@ A: No.  See above answer.  In short, if
    dash marker line as described in Documentation/SubmittingPatches to
    temporarily embed that information into the patch that you send.
 
+Q: Are all networking bug fixes backported to all stable releases?
+
+A: Due to capacity, Dave could only take care of the backports for the last
+   2 stable releases. For earlier stable releases, each stable branch maintainer
+   is supposed to take care of them. If you find any patch is missing from an
+   earlier stable branch, please notify stable@vger.kernel.org with either a
+   commit ID or a formal patch backported, and CC Dave and other relevant
+   networking developers.
+
 Q: Someone said that the comment style and coding convention is different
    for the networking content.  Is this true?
 

[PATCH 4.4 16/24] net/packet: refine check for priv area size

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit eb73190f4fbeedf762394e92d6a4ec9ace684c88 ]

syzbot was able to trick af_packet again [1]

Various commits tried to address the problem in the past,
but failed to take into account V3 header size.

[1]

tpacket_rcv: packet too big, clamped from 72 to 4294967224. macoff=96
BUG: KASAN: use-after-free in prb_run_all_ft_ops net/packet/af_packet.c:1016 [inline]
BUG: KASAN: use-after-free in prb_fill_curr_block.isra.59+0x4e5/0x5c0 net/packet/af_packet.c:1039
Write of size 2 at addr ffff8801cb62000e by task kworker/1:2/2106

CPU: 1 PID: 2106 Comm: kworker/1:2 Not tainted 4.17.0-rc7+ #77
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 print_address_description+0x6c/0x20b mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
 __asan_report_store2_noabort+0x17/0x20 mm/kasan/report.c:436
 prb_run_all_ft_ops net/packet/af_packet.c:1016 [inline]
 prb_fill_curr_block.isra.59+0x4e5/0x5c0 net/packet/af_packet.c:1039
 __packet_lookup_frame_in_block net/packet/af_packet.c:1094 [inline]
 packet_current_rx_frame net/packet/af_packet.c:1117 [inline]
 tpacket_rcv+0x1866/0x3340 net/packet/af_packet.c:2282
 dev_queue_xmit_nit+0x891/0xb90 net/core/dev.c:2018
 xmit_one net/core/dev.c:3049 [inline]
 dev_hard_start_xmit+0x16b/0xc10 net/core/dev.c:3069
 __dev_queue_xmit+0x2724/0x34c0 net/core/dev.c:3584
 dev_queue_xmit+0x17/0x20 net/core/dev.c:3617
 neigh_resolve_output+0x679/0xad0 net/core/neighbour.c:1358
 neigh_output include/net/neighbour.h:482 [inline]
 ip6_finish_output2+0xc9c/0x2810 net/ipv6/ip6_output.c:120
 ip6_finish_output+0x5fe/0xbc0 net/ipv6/ip6_output.c:154
 NF_HOOK_COND include/linux/netfilter.h:277 [inline]
 ip6_output+0x227/0x9b0 net/ipv6/ip6_output.c:171
 dst_output include/net/dst.h:444 [inline]
 NF_HOOK include/linux/netfilter.h:288 [inline]
 ndisc_send_skb+0x100d/0x1570 net/ipv6/ndisc.c:491
 ndisc_send_ns+0x3c1/0x8d0 net/ipv6/ndisc.c:633
 addrconf_dad_work+0xbef/0x1340 net/ipv6/addrconf.c:4033
 process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145
 worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279
 kthread+0x345/0x410 kernel/kthread.c:240
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412

The buggy address belongs to the page:
page:ffffea00072d8800 count:0 mapcount:-127 mapping:0000000000000000 index:0xffff8801cb620e80
flags: 0x2fffc0000000000()
raw: 02fffc0000000000 0000000000000000 ffff8801cb620e80 00000000ffffff80
raw: ffffea00072e3820 ffffea0007132d20 0000000000000002 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8801cb61ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff8801cb61ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8801cb620000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                      ^
 ffff8801cb620080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff8801cb620100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Fixes: 2b6867c2ce76 ("net/packet: fix overflow in check for priv area size")
Fixes: dc808110bb62 ("packet: handle too big packets for PACKET_V3")
Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/packet/af_packet.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -4198,7 +4198,7 @@ static int packet_set_ring(struct sock *
 			goto out;
 		if (po->tp_version >= TPACKET_V3 &&
 		    req->tp_block_size <=
-			  BLK_PLUS_PRIV((u64)req_u->req3.tp_sizeof_priv))
+		    BLK_PLUS_PRIV((u64)req_u->req3.tp_sizeof_priv) + sizeof(struct tpacket3_hdr))
 			goto out;
 		if (unlikely(req->tp_frame_size < po->tp_hdrlen +
 					po->tp_reserve))

[PATCH 4.4 18/24] packet: fix reserve calculation

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Willem de Bruijn <willemb@google.com>

[ Upstream commit 9aad13b087ab0a588cd68259de618f100053360e ]

Commit b84bbaf7a6c8 ("packet: in packet_snd start writing at link
layer allocation") ensures that packet_snd always starts writing
the link layer header in reserved headroom allocated for this
purpose.

This is needed because packets may be shorter than hard_header_len,
in which case the space up to hard_header_len may be zeroed. But
that necessary padding is not accounted for in skb->len.

The fix, however, is buggy. It calls skb_push, which grows skb->len
when moving skb->data back. But in this case packet length should not
change.

Instead, call skb_reserve, which moves both skb->data and skb->tail
back, without changing length.

Fixes: b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation")
Reported-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/packet/af_packet.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2779,7 +2779,7 @@ static int packet_snd(struct socket *soc
 		if (unlikely(offset < 0))
 			goto out_free;
 	} else if (reserve) {
-		skb_push(skb, reserve);
+		skb_reserve(skb, -reserve);
 	}
 
 	/* Returns -EFAULT on error */

[PATCH 4.4 19/24] qed: Fix mask for physical address in ILT entry

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Shahed Shaikh <shahed.shaikh@cavium.com>

[ Upstream commit fdd13dd350dda1826579eb5c333d76b14513b812 ]

ILT entry requires 12 bit right shifted physical address.
Existing mask for ILT entry of physical address i.e.
ILT_ENTRY_PHY_ADDR_MASK is not sufficient to handle 64bit
address because upper 8 bits of 64 bit address were getting
masked which resulted in completer abort error on
PCIe bus due to invalid address.

Fix that mask to handle 64bit physical address.

Fixes: fe56b9e6a8d9 ("qed: Add module with basic common support")
Signed-off-by: Shahed Shaikh <shahed.shaikh@cavium.com>
Signed-off-by: Ariel Elior <ariel.elior@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/qlogic/qed/qed_cxt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -43,7 +43,7 @@
 #define ILT_CFG_REG(cli, reg)	PSWRQ2_REG_ ## cli ## _ ## reg ## _RT_OFFSET
 
 /* ILT entry structure */
-#define ILT_ENTRY_PHY_ADDR_MASK		0x000FFFFFFFFFFFULL
+#define ILT_ENTRY_PHY_ADDR_MASK		(~0ULL >> 12)
 #define ILT_ENTRY_PHY_ADDR_SHIFT	0
 #define ILT_ENTRY_VALID_MASK		0x1ULL
 #define ILT_ENTRY_VALID_SHIFT		52

[PATCH 4.4 20/24] net/mlx4: Fix irq-unsafe spinlock usage

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jack Morgenstein <jackm@dev.mellanox.co.il>

[ Upstream commit d546b67cda015fb92bfee93d5dc0ceadb91deaee ]

spin_lock/unlock was used instead of spin_un/lock_irq
in a procedure used in process space, on a spinlock
which can be grabbed in an interrupt.

This caused the stack trace below to be displayed (on kernel
4.17.0-rc1 compiled with Lock Debugging enabled):

[  154.661474] WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
[  154.668909] 4.17.0-rc1-rdma_rc_mlx+ #3 Tainted: G          I
[  154.675856] -----------------------------------------------------
[  154.682706] modprobe/10159 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[  154.690254] 00000000f3b0e495 (&(&qp_table->lock)->rlock){+.+.}, at: mlx4_qp_remove+0x20/0x50 [mlx4_core]
[  154.700927]
and this task is already holding:
[  154.707461] 0000000094373b5d (&(&cq->lock)->rlock/1){....}, at: destroy_qp_common+0x111/0x560 [mlx4_ib]
[  154.718028] which would create a new lock dependency:
[  154.723705]  (&(&cq->lock)->rlock/1){....} -> (&(&qp_table->lock)->rlock){+.+.}
[  154.731922]
but this new dependency connects a SOFTIRQ-irq-safe lock:
[  154.740798]  (&(&cq->lock)->rlock){..-.}
[  154.740800]
... which became SOFTIRQ-irq-safe at:
[  154.752163]   _raw_spin_lock_irqsave+0x3e/0x50
[  154.757163]   mlx4_ib_poll_cq+0x36/0x900 [mlx4_ib]
[  154.762554]   ipoib_tx_poll+0x4a/0xf0 [ib_ipoib]
...
to a SOFTIRQ-irq-unsafe lock:
[  154.815603]  (&(&qp_table->lock)->rlock){+.+.}
[  154.815604]
... which became SOFTIRQ-irq-unsafe at:
[  154.827718] ...
[  154.827720]   _raw_spin_lock+0x35/0x50
[  154.833912]   mlx4_qp_lookup+0x1e/0x50 [mlx4_core]
[  154.839302]   mlx4_flow_attach+0x3f/0x3d0 [mlx4_core]

Since mlx4_qp_lookup() is called only in process space, we can
simply replace the spin_un/lock calls with spin_un/lock_irq calls.

Fixes: 6dc06c08bef1 ("net/mlx4: Fix the check in attaching steering rules")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/mellanox/mlx4/qp.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/ethernet/mellanox/mlx4/qp.c
+++ b/drivers/net/ethernet/mellanox/mlx4/qp.c
@@ -386,11 +386,11 @@ struct mlx4_qp *mlx4_qp_lookup(struct ml
 	struct mlx4_qp_table *qp_table = &mlx4_priv(dev)->qp_table;
 	struct mlx4_qp *qp;
 
-	spin_lock(&qp_table->lock);
+	spin_lock_irq(&qp_table->lock);
 
 	qp = __mlx4_qp_lookup(dev, qpn);
 
-	spin_unlock(&qp_table->lock);
+	spin_unlock_irq(&qp_table->lock);
 	return qp;
 }
 

[PATCH 4.4 21/24] team: use netdev_features_t instead of u32

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Dan Carpenter <dan.carpenter@oracle.com>

[ Upstream commit 25ea66544bfd1d9df1b7e1502f8717e85fa1e6e6 ]

This code was introduced in 2011 around the same time that we made
netdev_features_t a u64 type.  These days a u32 is not big enough to
hold all the potential features.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/team/team.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -983,7 +983,8 @@ static void team_port_disable(struct tea
 static void ___team_compute_features(struct team *team)
 {
 	struct team_port *port;
-	u32 vlan_features = TEAM_VLAN_FEATURES & NETIF_F_ALL_FOR_ALL;
+	netdev_features_t vlan_features = TEAM_VLAN_FEATURES &
+					  NETIF_F_ALL_FOR_ALL;
 	unsigned short max_hard_header_len = ETH_HLEN;
 	unsigned int dst_release_flag = IFF_XMIT_DST_RELEASE |
 					IFF_XMIT_DST_RELEASE_PERM;

[PATCH 4.4 22/24] rtnetlink: validate attributes in do_setlink()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit 644c7eebbfd59e72982d11ec6cc7d39af12450ae ]

It seems that rtnl_group_changelink() can call do_setlink
while a prior call to validate_linkmsg(dev = NULL, ...) could
not validate IFLA_ADDRESS / IFLA_BROADCAST

Make sure do_setlink() calls validate_linkmsg() instead
of letting its callers having this responsibility.

With help from Dmitry Vyukov, thanks a lot !

BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:199 [inline]
BUG: KMSAN: uninit-value in eth_prepare_mac_addr_change net/ethernet/eth.c:275 [inline]
BUG: KMSAN: uninit-value in eth_mac_addr+0x203/0x2b0 net/ethernet/eth.c:308
CPU: 1 PID: 8695 Comm: syz-executor3 Not tainted 4.17.0-rc5+ #103
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:113
 kmsan_report+0x149/0x260 mm/kmsan/kmsan.c:1084
 __msan_warning_32+0x6e/0xc0 mm/kmsan/kmsan_instr.c:686
 is_valid_ether_addr include/linux/etherdevice.h:199 [inline]
 eth_prepare_mac_addr_change net/ethernet/eth.c:275 [inline]
 eth_mac_addr+0x203/0x2b0 net/ethernet/eth.c:308
 dev_set_mac_address+0x261/0x530 net/core/dev.c:7157
 do_setlink+0xbc3/0x5fc0 net/core/rtnetlink.c:2317
 rtnl_group_changelink net/core/rtnetlink.c:2824 [inline]
 rtnl_newlink+0x1fe9/0x37a0 net/core/rtnetlink.c:2976
 rtnetlink_rcv_msg+0xa32/0x1560 net/core/rtnetlink.c:4646
 netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2448
 rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4664
 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
 netlink_unicast+0x1678/0x1750 net/netlink/af_netlink.c:1336
 netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg net/socket.c:639 [inline]
 ___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
 __sys_sendmsg net/socket.c:2155 [inline]
 __do_sys_sendmsg net/socket.c:2164 [inline]
 __se_sys_sendmsg net/socket.c:2162 [inline]
 __x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
 do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x455a09
RSP: 002b:00007fc07480ec68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fc07480f6d4 RCX: 0000000000455a09
RDX: 0000000000000000 RSI: 00000000200003c0 RDI: 0000000000000014
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000005d0 R14: 00000000006fdc20 R15: 0000000000000000

Uninit was stored to memory at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
 kmsan_save_stack mm/kmsan/kmsan.c:294 [inline]
 kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:685
 kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:527
 __msan_memcpy+0x109/0x160 mm/kmsan/kmsan_instr.c:478
 do_setlink+0xb84/0x5fc0 net/core/rtnetlink.c:2315
 rtnl_group_changelink net/core/rtnetlink.c:2824 [inline]
 rtnl_newlink+0x1fe9/0x37a0 net/core/rtnetlink.c:2976
 rtnetlink_rcv_msg+0xa32/0x1560 net/core/rtnetlink.c:4646
 netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2448
 rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4664
 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
 netlink_unicast+0x1678/0x1750 net/netlink/af_netlink.c:1336
 netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg net/socket.c:639 [inline]
 ___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
 __sys_sendmsg net/socket.c:2155 [inline]
 __do_sys_sendmsg net/socket.c:2164 [inline]
 __se_sys_sendmsg net/socket.c:2162 [inline]
 __x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
 do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
 kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189
 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315
 kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan.c:322
 slab_post_alloc_hook mm/slab.h:446 [inline]
 slab_alloc_node mm/slub.c:2753 [inline]
 __kmalloc_node_track_caller+0xb32/0x11b0 mm/slub.c:4395
 __kmalloc_reserve net/core/skbuff.c:138 [inline]
 __alloc_skb+0x2cb/0x9e0 net/core/skbuff.c:206
 alloc_skb include/linux/skbuff.h:988 [inline]
 netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline]
 netlink_sendmsg+0x76e/0x1350 net/netlink/af_netlink.c:1876
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg net/socket.c:639 [inline]
 ___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
 __sys_sendmsg net/socket.c:2155 [inline]
 __do_sys_sendmsg net/socket.c:2164 [inline]
 __se_sys_sendmsg net/socket.c:2162 [inline]
 __x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
 do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: e7ed828f10bd ("netlink: support setting devgroup parameters")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/core/rtnetlink.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1691,6 +1691,10 @@ static int do_setlink(const struct sk_bu
 	const struct net_device_ops *ops = dev->netdev_ops;
 	int err;
 
+	err = validate_linkmsg(dev, tb);
+	if (err < 0)
+		return err;
+
 	if (tb[IFLA_NET_NS_PID] || tb[IFLA_NET_NS_FD]) {
 		struct net *net = rtnl_link_get_net(dev_net(dev), tb);
 		if (IS_ERR(net)) {
@@ -1982,10 +1986,6 @@ static int rtnl_setlink(struct sk_buff *
 		goto errout;
 	}
 
-	err = validate_linkmsg(dev, tb);
-	if (err < 0)
-		goto errout;
-
 	err = do_setlink(skb, dev, ifm, tb, ifname, 0);
 errout:
 	return err;

[PATCH 4.4 23/24] net: phy: broadcom: Fix bcm_write_exp()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Florian Fainelli <f.fainelli@gmail.com>

[ Upstream commit 79fb218d97980d4fee9a64f4c8ff05289364ba25 ]

On newer PHYs, we need to select the expansion register to write with
setting bits [11:8] to 0xf. This was done correctly by bcm7xxx.c prior
to being migrated to generic code under bcm-phy-lib.c which
unfortunately used the older implementation from the BCM54xx days.

Fix this by creating an inline stub: bcm_write_exp_sel() which adds the
correct value (MII_BCM54XX_EXP_SEL_ER) and update both the Cygnus PHY
and BCM7xxx PHY drivers which require setting these bits.

broadcom.c is unchanged because some PHYs even use a different selector
method, so let them specify it directly (e.g: SerDes secondary selector).

Fixes: a1cba5613edf ("net: phy: Add Broadcom phy library for common interfaces")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/phy/bcm-cygnus.c  |    6 +++---
 drivers/net/phy/bcm-phy-lib.h |    7 +++++++
 drivers/net/phy/bcm7xxx.c     |    4 ++--
 3 files changed, 12 insertions(+), 5 deletions(-)

--- a/drivers/net/phy/bcm-cygnus.c
+++ b/drivers/net/phy/bcm-cygnus.c
@@ -61,17 +61,17 @@ static int bcm_cygnus_afe_config(struct
 		return rc;
 
 	/* make rcal=100, since rdb default is 000 */
-	rc = bcm_phy_write_exp(phydev, MII_BRCM_CORE_EXPB1, 0x10);
+	rc = bcm_phy_write_exp_sel(phydev, MII_BRCM_CORE_EXPB1, 0x10);
 	if (rc < 0)
 		return rc;
 
 	/* CORE_EXPB0, Reset R_CAL/RC_CAL Engine */
-	rc = bcm_phy_write_exp(phydev, MII_BRCM_CORE_EXPB0, 0x10);
+	rc = bcm_phy_write_exp_sel(phydev, MII_BRCM_CORE_EXPB0, 0x10);
 	if (rc < 0)
 		return rc;
 
 	/* CORE_EXPB0, Disable Reset R_CAL/RC_CAL Engine */
-	rc = bcm_phy_write_exp(phydev, MII_BRCM_CORE_EXPB0, 0x00);
+	rc = bcm_phy_write_exp_sel(phydev, MII_BRCM_CORE_EXPB0, 0x00);
 
 	return 0;
 }
--- a/drivers/net/phy/bcm-phy-lib.h
+++ b/drivers/net/phy/bcm-phy-lib.h
@@ -14,11 +14,18 @@
 #ifndef _LINUX_BCM_PHY_LIB_H
 #define _LINUX_BCM_PHY_LIB_H
 
+#include <linux/brcmphy.h>
 #include <linux/phy.h>
 
 int bcm_phy_write_exp(struct phy_device *phydev, u16 reg, u16 val);
 int bcm_phy_read_exp(struct phy_device *phydev, u16 reg);
 
+static inline int bcm_phy_write_exp_sel(struct phy_device *phydev,
+					u16 reg, u16 val)
+{
+	return bcm_phy_write_exp(phydev, reg | MII_BCM54XX_EXP_SEL_ER, val);
+}
+
 int bcm_phy_write_misc(struct phy_device *phydev,
 		       u16 reg, u16 chl, u16 value);
 int bcm_phy_read_misc(struct phy_device *phydev,
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -48,10 +48,10 @@
 static void r_rc_cal_reset(struct phy_device *phydev)
 {
 	/* Reset R_CAL/RC_CAL Engine */
-	bcm_phy_write_exp(phydev, 0x00b0, 0x0010);
+	bcm_phy_write_exp_sel(phydev, 0x00b0, 0x0010);
 
 	/* Disable Reset R_AL/RC_CAL Engine */
-	bcm_phy_write_exp(phydev, 0x00b0, 0x0000);
+	bcm_phy_write_exp_sel(phydev, 0x00b0, 0x0000);
 }
 
 static int bcm7xxx_28nm_b0_afe_config_init(struct phy_device *phydev)

[PATCH 4.4 24/24] net: metrics: add proper netlink validation

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit 5b5e7a0de2bbf2a1afcd9f49e940010e9fb80d53 ]

Before using nla_get_u32(), better make sure the attribute
is of the proper size.

Code recently was changed, but bug has been there from beginning
of git.

BUG: KMSAN: uninit-value in rtnetlink_put_metrics+0x553/0x960 net/core/rtnetlink.c:746
CPU: 1 PID: 14139 Comm: syz-executor6 Not tainted 4.17.0-rc5+ #103
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:113
 kmsan_report+0x149/0x260 mm/kmsan/kmsan.c:1084
 __msan_warning_32+0x6e/0xc0 mm/kmsan/kmsan_instr.c:686
 rtnetlink_put_metrics+0x553/0x960 net/core/rtnetlink.c:746
 fib_dump_info+0xc42/0x2190 net/ipv4/fib_semantics.c:1361
 rtmsg_fib+0x65f/0x8c0 net/ipv4/fib_semantics.c:419
 fib_table_insert+0x2314/0x2b50 net/ipv4/fib_trie.c:1287
 inet_rtm_newroute+0x210/0x340 net/ipv4/fib_frontend.c:779
 rtnetlink_rcv_msg+0xa32/0x1560 net/core/rtnetlink.c:4646
 netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2448
 rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4664
 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
 netlink_unicast+0x1678/0x1750 net/netlink/af_netlink.c:1336
 netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg net/socket.c:639 [inline]
 ___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
 __sys_sendmsg net/socket.c:2155 [inline]
 __do_sys_sendmsg net/socket.c:2164 [inline]
 __se_sys_sendmsg net/socket.c:2162 [inline]
 __x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
 do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x455a09
RSP: 002b:00007faae5fd8c68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007faae5fd96d4 RCX: 0000000000455a09
RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000005d0 R14: 00000000006fdc20 R15: 0000000000000000

Uninit was stored to memory at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
 kmsan_save_stack mm/kmsan/kmsan.c:294 [inline]
 kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:685
 __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:529
 fib_convert_metrics net/ipv4/fib_semantics.c:1056 [inline]
 fib_create_info+0x2d46/0x9dc0 net/ipv4/fib_semantics.c:1150
 fib_table_insert+0x3e4/0x2b50 net/ipv4/fib_trie.c:1146
 inet_rtm_newroute+0x210/0x340 net/ipv4/fib_frontend.c:779
 rtnetlink_rcv_msg+0xa32/0x1560 net/core/rtnetlink.c:4646
 netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2448
 rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4664
 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
 netlink_unicast+0x1678/0x1750 net/netlink/af_netlink.c:1336
 netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg net/socket.c:639 [inline]
 ___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
 __sys_sendmsg net/socket.c:2155 [inline]
 __do_sys_sendmsg net/socket.c:2164 [inline]
 __se_sys_sendmsg net/socket.c:2162 [inline]
 __x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
 do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
 kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189
 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315
 kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan.c:322
 slab_post_alloc_hook mm/slab.h:446 [inline]
 slab_alloc_node mm/slub.c:2753 [inline]
 __kmalloc_node_track_caller+0xb32/0x11b0 mm/slub.c:4395
 __kmalloc_reserve net/core/skbuff.c:138 [inline]
 __alloc_skb+0x2cb/0x9e0 net/core/skbuff.c:206
 alloc_skb include/linux/skbuff.h:988 [inline]
 netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline]
 netlink_sendmsg+0x76e/0x1350 net/netlink/af_netlink.c:1876
 sock_sendmsg_nosec net/socket.c:629 [inline]
 sock_sendmsg net/socket.c:639 [inline]
 ___sys_sendmsg+0xec0/0x1310 net/socket.c:2117
 __sys_sendmsg net/socket.c:2155 [inline]
 __do_sys_sendmsg net/socket.c:2164 [inline]
 __se_sys_sendmsg net/socket.c:2162 [inline]
 __x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
 do_syscall_64+0x152/0x230 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: a919525ad832 ("net: Move fib_convert_metrics to metrics file")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv4/fib_semantics.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -979,6 +979,8 @@ fib_convert_metrics(struct fib_info *fi,
 			if (val == TCP_CA_UNSPEC)
 				return -EINVAL;
 		} else {
+			if (nla_len(nla) != sizeof(u32))
+				return false;
 			val = nla_get_u32(nla);
 		}
 		if (type == RTAX_ADVMSS && val > 65535 - 40)

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

[Nathan Chancellor]

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.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
> 

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

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

[Greg Kroah-Hartman]

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.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
> > 
> 
> 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

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

[Shuah Khan]

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.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
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

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

[Guenter Roeck]

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

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

[Rafael Tinoco]

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] 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

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

[Greg Kroah-Hartman]

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?

thanks,

greg k-h

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

[Rafael David Tinoco]

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.

> 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

Re: [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

[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.

Re: [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

[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

Re: [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

[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

Re: [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

[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

Re: [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

[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
> 

Re: [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

[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

Re: [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

[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

Re: [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

[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

Re: [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

[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

Re: [PATCH 4.4 24/24] net: metrics: add proper netlink validation

[Ben Hutchings]

On Tue, 2018-06-12 at 18:52 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Eric Dumazet <edumazet@google.com>
> 
> [ Upstream commit 5b5e7a0de2bbf2a1afcd9f49e940010e9fb80d53 ]
[...]
> --- a/net/ipv4/fib_semantics.c
> +++ b/net/ipv4/fib_semantics.c
> @@ -979,6 +979,8 @@ fib_convert_metrics(struct fib_info *fi,
>  			if (val == TCP_CA_UNSPEC)
>  				return -EINVAL;
>  		} else {
> +			if (nla_len(nla) != sizeof(u32))
> +				return false;

For 4.4 and 4.9, the return value on error needs to be -EINVAL.

Ben.

>  			val = nla_get_u32(nla);
>  		}
>  		if (type == RTAX_ADVMSS && val > 65535 - 40)

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom