3.14.70-stable review

This is the start of the stable review cycle for the 3.14.70 release. There are 17 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 May 19 01:13:32 UTC 2016. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.14.70-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 3.14.70-rc1

Jon Medhurst <[email protected]>
arm64: Make arch_randomize_brk avoid stack area

Kangjie Lu <[email protected]>
net: fix a kernel infoleak in x25 module

Nikolay Aleksandrov <[email protected]>
net: bridge: fix old ioctl unlocked net device walk

Ian Campbell <[email protected]>
VSOCK: do not disconnect socket when peer has shutdown SEND only

Kangjie Lu <[email protected]>
net: fix infoleak in rtnetlink

Kangjie Lu <[email protected]>
net: fix infoleak in llc

Ben Hutchings <[email protected]>
atl2: Disable unimplemented scatter/gather feature

Mathias Krause <[email protected]>
packet: fix heap info leak in PACKET_DIAG_MCLIST sock_diag interface

Chris Friesen <[email protected]>
route: do not cache fib route info on local routes with oif

David S. Miller <[email protected]>
decnet: Do not build routes to devices without decnet private data.

Tony Lindgren <[email protected]>
ARM: OMAP3: Fix booting with thumb2 kernel

Daniel Vetter <[email protected]>
drm/i915: Bail out of pipe config compute loop on LPT

Lucas Stach <[email protected]>
drm/radeon: fix PLL sharing on DCE6.1 (v2)

Andi Kleen <[email protected]>
asmlinkage, pnp: Make variables used from assembler code visible

Marek Szyprowski <[email protected]>
Input: max8997-haptic - fix NULL pointer dereference

Al Viro <[email protected]>
get_rock_ridge_filename(): handle malformed NM entries

Herbert Xu <[email protected]>
crypto: hash - Fix page length clamping in hash walk

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

Diffstat:

 Makefile                                 |  4 ++--
 arch/arm/mach-omap2/sleep34xx.S          | 22 ++--------------------
 arch/arm64/kernel/process.c              | 24 ++++++++++++++++++------
 crypto/ahash.c                           |  3 ++-
 drivers/gpu/drm/i915/intel_crt.c         |  8 +++++++-
 drivers/gpu/drm/radeon/atombios_crtc.c   | 10 ++++++++++
 drivers/input/misc/max8997_haptic.c      |  6 ++++--
 drivers/net/ethernet/atheros/atlx/atl2.c |  2 +-
 drivers/pnp/pnpbios/bioscalls.c          |  9 +++++----
 fs/isofs/rock.c                          | 13 ++++++++++---
 net/bridge/br_ioctl.c                    |  5 +++--
 net/core/rtnetlink.c                     | 18 ++++++++++--------
 net/decnet/dn_route.c                    |  9 ++++++++-
 net/ipv4/route.c                         | 12 ++++++++++++
 net/llc/af_llc.c                         |  1 +
 net/packet/af_packet.c                   |  1 +
 net/vmw_vsock/af_vsock.c                 | 21 +--------------------
 net/x25/x25_facilities.c                 |  1 +
 18 files changed, 98 insertions(+), 71 deletions(-)

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

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

From: Herbert Xu <[email protected]>

commit 13f4bb78cf6a312bbdec367ba3da044b09bf0e29 upstream.

The crypto hash walk code is broken when supplied with an offset greater than or equal to PAGE_SIZE. This patch fixes it by adjusting walk->pg and walk->offset when this happens.

---
 crypto/ahash.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

@@ -64,8 +64,9 @@ static int hash_walk_new_entry(struct cr
 	struct scatterlist *sg;
 
 	sg = walk->sg;
-	walk->pg = sg_page(sg);
 	walk->offset = sg->offset;
+	walk->pg = sg_page(walk->sg) + (walk->offset >> PAGE_SHIFT);
+	walk->offset = offset_in_page(walk->offset);
 	walk->entrylen = sg->length;
 
 	if (walk->entrylen > walk->total)

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

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

From: Al Viro <[email protected]>

commit 99d825822eade8d827a1817357cbf3f889a552d6 upstream.

Payloads of NM entries are not supposed to contain NUL. When we run into such, only the part prior to the first NUL goes into the concatenation (i.e. the directory entry name being encoded by a bunch of NM entries). We do stop when the amount collected so far + the claimed amount in the current NM entry exceed 254. So far, so good, but what we return as the total length is the sum of *claimed* sizes, not the actual amount collected. And that can grow pretty large - not unlimited, since you'd need to put CE entries in between to be able to get more than the maximum that could be contained in one isofs directory entry / continuation chunk and we are stop once we'd encountered 32 CEs, but you can get about 8Kb easily. And that's what will be passed to readdir callback as the name length. 8Kb __copy_to_user() from a buffer allocated by __get_free_page()

---
 fs/isofs/rock.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

@@ -203,6 +203,8 @@ int get_rock_ridge_filename(struct iso_d
 	int retnamlen = 0;
 	int truncate = 0;
 	int ret = 0;
+	char *p;
+	int len;
 
 	if (!ISOFS_SB(inode->i_sb)->s_rock)
 		return 0;

@@ -267,12 +269,17 @@ repeat:
 					rr->u.NM.flags);
 				break;
 			}
-			if ((strlen(retname) + rr->len - 5) >= 254) {
+			len = rr->len - 5;
+			if (retnamlen + len >= 254) {
 				truncate = 1;
 				break;
 			}
-			strncat(retname, rr->u.NM.name, rr->len - 5);
-			retnamlen += rr->len - 5;
+			p = memchr(rr->u.NM.name, '\0', len);
+			if (unlikely(p))
+				len = p - rr->u.NM.name;
+			memcpy(retname + retnamlen, rr->u.NM.name, len);
+			retnamlen += len;
+			retname[retnamlen] = '\0';
 			break;
 		case SIG('R', 'E'):
 			kfree(rs.buffer);

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

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

From: Marek Szyprowski <[email protected]>

commit 6ae645d5fa385f3787bf1723639cd907fe5865e7 upstream.

NULL pointer derefence happens when booting with DTB because the platform data for haptic device is not set in supplied data from parent MFD device.

The MFD device creates only platform data (from Device Tree) for itself, not for haptic child.

Unable to handle kernel NULL pointer dereference at virtual address 0000009c
pgd = c0004000
	[0000009c] *pgd=00000000
	Internal error: Oops: 5 [#1] PREEMPT SMP ARM
	(max8997_haptic_probe) from [<c03f9cec>] (platform_drv_probe+0x4c/0xb0)
	(platform_drv_probe) from [<c03f8440>] (driver_probe_device+0x214/0x2c0)
	(driver_probe_device) from [<c03f8598>] (__driver_attach+0xac/0xb0)
	(__driver_attach) from [<c03f67ac>] (bus_for_each_dev+0x68/0x9c)
	(bus_for_each_dev) from [<c03f7a38>] (bus_add_driver+0x1a0/0x218)
	(bus_add_driver) from [<c03f8db0>] (driver_register+0x78/0xf8)
	(driver_register) from [<c0101774>] (do_one_initcall+0x90/0x1d8)
	(do_one_initcall) from [<c0a00dbc>] (kernel_init_freeable+0x15c/0x1fc)
	(kernel_init_freeable) from [<c06bb5b4>] (kernel_init+0x8/0x114)
	(kernel_init) from [<c0107938>] (ret_from_fork+0x14/0x3c)

---
 drivers/input/misc/max8997_haptic.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

@@ -245,12 +245,14 @@ static int max8997_haptic_probe(struct p
 	struct max8997_dev *iodev = dev_get_drvdata(pdev->dev.parent);
 	const struct max8997_platform_data *pdata =
 					dev_get_platdata(iodev->dev);
-	const struct max8997_haptic_platform_data *haptic_pdata =
-					pdata->haptic_pdata;
+	const struct max8997_haptic_platform_data *haptic_pdata = NULL;
 	struct max8997_haptic *chip;
 	struct input_dev *input_dev;
 	int error;
 
+	if (pdata)
+		haptic_pdata = pdata->haptic_pdata;
+
 	if (!haptic_pdata) {
 		dev_err(&pdev->dev, "no haptic platform data\n");
 		return -EINVAL;

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

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

From: Andi Kleen <[email protected]>

commit a99aa42d0253f033cbb85096d3f2bd82201321e6 upstream.

Mark variables referenced from assembler files visible.

This fixes compile problems with LTO.

---
 drivers/pnp/pnpbios/bioscalls.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

@@ -21,7 +21,7 @@
 
 #include "pnpbios.h"
 
-static struct {
+__visible struct {
 	u16 offset;
 	u16 segment;
 } pnp_bios_callpoint;

@@ -41,6 +41,7 @@ asmlinkage void pnp_bios_callfunc(void);
 
 __asm__(".text			\n"
 	__ALIGN_STR "\n"
+	".globl pnp_bios_callfunc\n"
 	"pnp_bios_callfunc:\n"
 	"	pushl %edx	\n"
 	"	pushl %ecx	\n"

@@ -66,9 +67,9 @@ static struct desc_struct bad_bios_desc
  * after PnP BIOS oopses.
  */
 
-u32 pnp_bios_fault_esp;
-u32 pnp_bios_fault_eip;
-u32 pnp_bios_is_utter_crap = 0;
+__visible u32 pnp_bios_fault_esp;
+__visible u32 pnp_bios_fault_eip;
+__visible u32 pnp_bios_is_utter_crap = 0;
 
 static spinlock_t pnp_bios_lock;
 

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

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

From: Lucas Stach <[email protected]>

commit e3c00d87845ab375f90fa6e10a5e72a3a5778cd3 upstream.

On DCE6.1 PPLL2 is exclusively available to UNIPHYA, so it should not be taken into consideration when looking for an already enabled PLL to be shared with other outputs.

This fixes the broken VGA port (TRAVIS DP->VGA bridge) on my Richland based laptop, where the internal display is connected to UNIPHYA through a TRAVIS DP->LVDS bridge.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=78987

v2: agd: add check in radeon_get_shared_nondp_ppll as well, drop
extra parameter.

---
 drivers/gpu/drm/radeon/atombios_crtc.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

@@ -1600,6 +1600,7 @@ static u32 radeon_get_pll_use_mask(struc
 static int radeon_get_shared_dp_ppll(struct drm_crtc *crtc)
 {
 	struct drm_device *dev = crtc->dev;
+	struct radeon_device *rdev = dev->dev_private;
 	struct drm_crtc *test_crtc;
 	struct radeon_crtc *test_radeon_crtc;
 

@@ -1609,6 +1610,10 @@ static int radeon_get_shared_dp_ppll(str
 		test_radeon_crtc = to_radeon_crtc(test_crtc);
 		if (test_radeon_crtc->encoder &&
 		    ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_radeon_crtc->encoder))) {
+			/* PPLL2 is exclusive to UNIPHYA on DCE61 */
+			if (ASIC_IS_DCE61(rdev) && !ASIC_IS_DCE8(rdev) &&
+			    test_radeon_crtc->pll_id == ATOM_PPLL2)
+				continue;
 			/* for DP use the same PLL for all */
 			if (test_radeon_crtc->pll_id != ATOM_PPLL_INVALID)
 				return test_radeon_crtc->pll_id;

@@ -1630,6 +1635,7 @@ static int radeon_get_shared_nondp_ppll(
 {
 	struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
 	struct drm_device *dev = crtc->dev;
+	struct radeon_device *rdev = dev->dev_private;
 	struct drm_crtc *test_crtc;
 	struct radeon_crtc *test_radeon_crtc;
 	u32 adjusted_clock, test_adjusted_clock;

@@ -1645,6 +1651,10 @@ static int radeon_get_shared_nondp_ppll(
 		test_radeon_crtc = to_radeon_crtc(test_crtc);
 		if (test_radeon_crtc->encoder &&
 		    !ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_radeon_crtc->encoder))) {
+			/* PPLL2 is exclusive to UNIPHYA on DCE61 */
+			if (ASIC_IS_DCE61(rdev) && !ASIC_IS_DCE8(rdev) &&
+			    test_radeon_crtc->pll_id == ATOM_PPLL2)
+				continue;
 			/* check if we are already driving this connector with another crtc */
 			if (test_radeon_crtc->connector == radeon_crtc->connector) {
 				/* if we are, return that pll */

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

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

From: Daniel Vetter <[email protected]>

commit 2700818ac9f935d8590715eecd7e8cadbca552b6 upstream.

LPT is pch, so might run into the fdi bandwidth constraint (especially since it has only 2 lanes). But right now we just force pipe_bpp back to 24, resulting in a nice loop (which we bail out with a loud WARN_ON). Fix this.

Cc: Chris Wilson <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
References: https://bugs.freedesktop.org/show_bug.cgi?id=93477

---
 drivers/gpu/drm/i915/intel_crt.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

@@ -259,8 +259,14 @@ static bool intel_crt_compute_config(str
 		pipe_config->has_pch_encoder = true;
 
 	/* LPT FDI RX only supports 8bpc. */
-	if (HAS_PCH_LPT(dev))
+	if (HAS_PCH_LPT(dev)) {
+		if (pipe_config->bw_constrained && pipe_config->pipe_bpp < 24) {
+			DRM_DEBUG_KMS("LPT only supports 24bpp\n");
+			return false;
+		}
+
 		pipe_config->pipe_bpp = 24;
+	}
 
 	return true;
 }

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

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

From: Tony Lindgren <[email protected]>

commit d8a50941c91a68da202aaa96a3dacd471ea9c693 upstream.

We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:

Internal error: Oops: 80000005 [#1] SMP THUMB2

...
[<c046497b>] (_raw_spin_unlock_irqrestore) from [<c0024375>] (omap3_enter_idle_bm+0xc5/0x178)
[<c0024375>] (omap3_enter_idle_bm) from [<c0374e63>] (cpuidle_enter_state+0x77/0x27c)
[<c0374e63>] (cpuidle_enter_state) from [<c00627f1>] (cpu_startup_entry+0x155/0x23c)
[<c00627f1>] (cpu_startup_entry) from [<c06b9a47>] (start_kernel+0x32f/0x338)
[<c06b9a47>] (start_kernel) from [<8000807f>] (0x8000807f)

The power management related assembly on omaps needs to interact with ARM mode bootrom code, so we need to keep most of the related assembly in ARM mode.

Turns out this error is because of missing ENDPROC for assembly code as suggested by Stephen Boyd <[email protected]>. Let's fix the problem by adding ENDPROC in two places to sleep34xx.S.

Let's also remove the now duplicate custom code for mode switching. This has been unnecessary since commit 6ebbf2ce437b ("ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+").

And let's also remove the comments about local variables, they are now just confusing after the ENDPROC.

The reason why ENDPROC makes a difference is it sets .type and then the compiler knows what to do with the thumb bit as explained at:

https://wiki.ubuntu.com/ARM/Thumb2PortingHowto

---
 arch/arm/mach-omap2/sleep34xx.S |   22 ++--------------------
 1 file changed, 2 insertions(+), 20 deletions(-)

@@ -203,23 +203,8 @@ save_context_wfi:
 	 */
 	ldr	r1, kernel_flush
 	blx	r1
-	/*
-	 * The kernel doesn't interwork: v7_flush_dcache_all in particluar will
-	 * always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
-	 * This sequence switches back to ARM.  Note that .align may insert a
-	 * nop: bx pc needs to be word-aligned in order to work.
-	 */
- THUMB(	.thumb		)
- THUMB(	.align		)
- THUMB(	bx	pc	)
- THUMB(	nop		)
-	.arm
-
 	b	omap3_do_wfi
-
-/*
- * Local variables
- */
+ENDPROC(omap34xx_cpu_suspend)
 omap3_do_wfi_sram_addr:
 	.word omap3_do_wfi_sram
 kernel_flush:

@@ -364,10 +349,7 @@ exit_nonoff_modes:
  * ===================================
  */
 	ldmfd	sp!, {r4 - r11, pc}	@ restore regs and return
-
-/*
- * Local variables
- */
+ENDPROC(omap3_do_wfi)
 sdrc_power:
 	.word	SDRC_POWER_V
 cm_idlest1_core:

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

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

From: "David S. Miller" <[email protected]>

[ Upstream commit a36a0d4008488fa545c74445d69eaf56377d5d4e ]

In particular, make sure we check for decnet private presence for loopback devices.

---
 net/decnet/dn_route.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

@@ -1030,10 +1030,13 @@ source_ok:
 	if (!fld.daddr) {
 		fld.daddr = fld.saddr;
 
-		err = -EADDRNOTAVAIL;
 		if (dev_out)
 			dev_put(dev_out);
+		err = -EINVAL;
 		dev_out = init_net.loopback_dev;
+		if (!dev_out->dn_ptr)
+			goto out;
+		err = -EADDRNOTAVAIL;
 		dev_hold(dev_out);
 		if (!fld.daddr) {
 			fld.daddr =

@@ -1106,6 +1109,8 @@ source_ok:
 		if (dev_out == NULL)
 			goto out;
 		dn_db = rcu_dereference_raw(dev_out->dn_ptr);
+		if (!dn_db)
+			goto e_inval;
 		/* Possible improvement - check all devices for local addr */
 		if (dn_dev_islocal(dev_out, fld.daddr)) {
 			dev_put(dev_out);

@@ -1147,6 +1152,8 @@ select_source:
 			dev_put(dev_out);
 		dev_out = init_net.loopback_dev;
 		dev_hold(dev_out);
+		if (!dev_out->dn_ptr)
+			goto e_inval;
 		fld.flowidn_oif = dev_out->ifindex;
 		if (res.fi)
 			dn_fib_info_put(res.fi);

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

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

From: Chris Friesen <[email protected]>

[ Upstream commit d6d5e999e5df67f8ec20b6be45e2229455ee3699 ]

For local routes that require a particular output interface we do not want to cache the result. Caching the result causes incorrect behaviour when there are multiple source addresses on the interface. The end result being that if the intended recipient is waiting on that interface for the packet he won't receive it because it will be delivered on the loopback interface and the IP_PKTINFO ipi_ifindex will be set to the loopback interface as well.

This can be tested by running a program such as "dhcp_release" which attempts to inject a packet on a particular interface so that it is received by another program on the same board. The receiving process should see an IP_PKTINFO ipi_ifndex value of the source interface (e.g., eth1) instead of the loopback interface (e.g., lo). The packet will still appear on the loopback interface in tcpdump but the important aspect is that the CMSG info is correct.

Sample dhcp_release command line:

dhcp_release eth1 192.168.204.222 02:11:33:22:44:66

Signed off-by: Chris Friesen <[email protected]>

---
 net/ipv4/route.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

@@ -1926,6 +1926,18 @@ static struct rtable *__mkroute_output(c
 		 */
 		if (fi && res->prefixlen < 4)
 			fi = NULL;
+	} else if ((type == RTN_LOCAL) && (orig_oif != 0) &&
+		   (orig_oif != dev_out->ifindex)) {
+		/* For local routes that require a particular output interface
+		 * we do not want to cache the result.  Caching the result
+		 * causes incorrect behaviour when there are multiple source
+		 * addresses on the interface, the end result being that if the
+		 * intended recipient is waiting on that interface for the
+		 * packet he won't receive it because it will be delivered on
+		 * the loopback interface and the IP_PKTINFO ipi_ifindex will
+		 * be set to the loopback interface as well.
+		 */
+		fi = NULL;
 	}
 
 	fnhe = NULL;

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

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

From: Mathias Krause <[email protected]>

[ Upstream commit 309cf37fe2a781279b7675d4bb7173198e532867 ]

Because we miss to wipe the remainder of i->addr[] in packet_mc_add(), pdiag_put_mclist() leaks uninitialized heap bytes via the PACKET_DIAG_MCLIST netlink attribute.

Fix this by explicitly memset(0)ing the remaining bytes in i->addr[].

---
 net/packet/af_packet.c |    1 +
 1 file changed, 1 insertion(+)

@@ -3153,6 +3153,7 @@ static int packet_mc_add(struct sock *sk
 	i->ifindex = mreq->mr_ifindex;
 	i->alen = mreq->mr_alen;
 	memcpy(i->addr, mreq->mr_address, i->alen);
+	memset(i->addr + i->alen, 0, sizeof(i->addr) - i->alen);
 	i->count = 1;
 	i->next = po->mclist;
 	po->mclist = i;

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

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

From: Ben Hutchings <[email protected]>

[ Upstream commit f43bfaeddc79effbf3d0fcb53ca477cca66f3db8 ]

atl2 includes NETIF_F_SG in hw_features even though it has no support for non-linear skbs. This bug was originally harmless since the driver does not claim to implement checksum offload and that used to be a requirement for SG.

Now that SG and checksum offload are independent features, if you explicitly enable SG *and* use one of the rare protocols that can use SG without checkusm offload, this potentially leaks sensitive information (before you notice that it just isn't working). Therefore this obscure bug has been designated CVE-2016-2117.

---
 drivers/net/ethernet/atheros/atlx/atl2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -1413,7 +1413,7 @@ static int atl2_probe(struct pci_dev *pd
 
 	err = -EIO;
 
-	netdev->hw_features = NETIF_F_SG | NETIF_F_HW_VLAN_CTAG_RX;
+	netdev->hw_features = NETIF_F_HW_VLAN_CTAG_RX;
 	netdev->features |= (NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX);
 
 	/* Init PHY as early as possible due to power saving issue  */

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

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

From: Ian Campbell <[email protected]>

[ Upstream commit dedc58e067d8c379a15a8a183c5db318201295bb ]

The peer may be expecting a reply having sent a request and then done a shutdown(SHUT_WR), so tearing down the whole socket at this point seems wrong and breaks for me with a client which does a SHUT_WR.

Looking at other socket family's stream_recvmsg callbacks doing a shutdown here does not seem to be the norm and removing it does not seem to have had any adverse effects that I can see.

I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact on the vmci transport.

---
 net/vmw_vsock/af_vsock.c |   21 +--------------------
 1 file changed, 1 insertion(+), 20 deletions(-)

@@ -1796,27 +1796,8 @@ vsock_stream_recvmsg(struct kiocb *kiocb
 	else if (sk->sk_shutdown & RCV_SHUTDOWN)
 		err = 0;
 
-	if (copied > 0) {
-		/* We only do these additional bookkeeping/notification steps
-		 * if we actually copied something out of the queue pair
-		 * instead of just peeking ahead.
-		 */
-
-		if (!(flags & MSG_PEEK)) {
-			/* If the other side has shutdown for sending and there
-			 * is nothing more to read, then modify the socket
-			 * state.
-			 */
-			if (vsk->peer_shutdown & SEND_SHUTDOWN) {
-				if (vsock_stream_has_data(vsk) <= 0) {
-					sk->sk_state = SS_UNCONNECTED;
-					sock_set_flag(sk, SOCK_DONE);
-					sk->sk_state_change(sk);
-				}
-			}
-		}
+	if (copied > 0)
 		err = copied;
-	}
 
 out_wait:
 	finish_wait(sk_sleep(sk), &wait);

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

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

From: Nikolay Aleksandrov <[email protected]>

[ Upstream commit 31ca0458a61a502adb7ed192bf9716c6d05791a5 ]

get_bridge_ifindices() is used from the old "deviceless" bridge ioctl calls which aren't called with rtnl held. The comment above says that it is called with rtnl but that is not really the case.
Here's a sample output from a test ASSERT_RTNL() which I put in get_bridge_ifindices and executed "brctl show":

[  957.422726] RTNL: assertion failed at net/bridge//br_ioctl.c (30)
[  957.422925] CPU: 0 PID: 1862 Comm: brctl Tainted: G        W  O
4.6.0-rc4+ #157
[  957.423009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[  957.423009]  0000000000000000 ffff880058adfdf0 ffffffff8138dec5
0000000000000400
[  957.423009]  ffffffff81ce8380 ffff880058adfe58 ffffffffa05ead32
0000000000000001
[  957.423009]  00007ffec1a444b0 0000000000000400 ffff880053c19130
0000000000008940
[  957.423009] Call Trace:
[  957.423009]  [<ffffffff8138dec5>] dump_stack+0x85/0xc0
[  957.423009]  [<ffffffffa05ead32>]
br_ioctl_deviceless_stub+0x212/0x2e0 [bridge]
[  957.423009]  [<ffffffff81515beb>] sock_ioctl+0x22b/0x290
[  957.423009]  [<ffffffff8126ba75>] do_vfs_ioctl+0x95/0x700
[  957.423009]  [<ffffffff8126c159>] SyS_ioctl+0x79/0x90
[  957.423009]  [<ffffffff8163a4c0>] entry_SYSCALL_64_fastpath+0x23/0xc1

Since it only reads bridge ifindices, we can use rcu to safely walk the net device list. Also remove the wrong rtnl comment above.

---
 net/bridge/br_ioctl.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

@@ -21,18 +21,19 @@
 #include <asm/uaccess.h>
 #include "br_private.h"
 
-/* called with RTNL */
 static int get_bridge_ifindices(struct net *net, int *indices, int num)
 {
 	struct net_device *dev;
 	int i = 0;
 
-	for_each_netdev(net, dev) {
+	rcu_read_lock();
+	for_each_netdev_rcu(net, dev) {
 		if (i >= num)
 			break;
 		if (dev->priv_flags & IFF_EBRIDGE)
 			indices[i++] = dev->ifindex;
 	}
+	rcu_read_unlock();
 
 	return i;
 }

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

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

From: Kangjie Lu <[email protected]>

[ Upstream commit 79e48650320e6fba48369fccf13fd045315b19b8 ]

Stack object "dte_facilities" is allocated in x25_rx_call_request(), which is supposed to be initialized in x25_negotiate_facilities. However, 5 fields (8 bytes in total) are not initialized. This object is then copied to userland via copy_to_user, thus infoleak occurs.

---
 net/x25/x25_facilities.c |    1 +
 1 file changed, 1 insertion(+)

@@ -277,6 +277,7 @@ int x25_negotiate_facilities(struct sk_b
 
 	memset(&theirs, 0, sizeof(theirs));
 	memcpy(new, ours, sizeof(*new));
+	memset(dte, 0, sizeof(*dte));
 
 	len = x25_parse_facilities(skb, &theirs, dte, &x25->vc_facil_mask);
 	if (len < 0)

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

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

From: Jon Medhurst <[email protected]>

[As mentioned in the commit message, the problem this patch fixes can't occur in kernels with commit d1fd836dcf00, i.e Linux 4.1 and later., but earlier kernel versions need this fix.]

When a process is created, various address randomisations could end up colluding to place the address of brk in the stack memory. This would mean processes making small heap based memory allocations are in danger of having them overwriting, or overwritten by, the stack.

Another consequence, is that even for processes that make no use of brk, the output of /proc/*/maps may show the stack area listed as '[heap]' rather than '[stack]'. Apart from being misleading this causes fatal errors with the Android run-time like:
"No [stack] line found in /proc/self/task/*/maps"

To prevent this problem pick a limit for brk that allows for the stack's memory. At the same time we remove randomize_base() as that was only used by arch_randomize_brk().

Note, in practice, since commit d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR") this problem shouldn't occur because the address chosen for loading binaries is well clear of the stack, however, prior to that the problem does occur because of the following...

The memory layout of a task is determined by arch_pick_mmap_layout. If address randomisation is enabled (task has flag PF_RANDOMIZE) this sets mmap_base to a random address at the top of task memory just below a region calculated to allow for a stack which itself may have a random base address. Any mmap operations that then happen which require an address allocating will use the topdown allocation method, i.e. the first allocated memory will be at the top of memory, just below the area set aside for the stack.

When a relocatable binary is loaded into a new process by load_elf_binary and randomised address are enabled, it uses a 'load_bias' of zero, so that when mmap is called to create a memory region for it, a new address is picked (address zero not being available). As this is the first memory region in the task, it gets the region just below the stack, as described previously.

The loader then set's brk to the end of the elf data section, which will be near the end of the loaded binary and then it calls arch_randomize_brk. As this currently stands, this adds a random amount to brk, which unfortunately may take it into the address range where the stack lies.

Testing:

These changes have been tested on Linux 3.18 (where the collision of brk and stack can happen) using 100000 invocations of a program [1] that can display the offset of a process's brk...

$for i in $(seq 100000); do ./aslr --report brk ; done

This shows values of brk are evenly distributed over a 1GB range before this change is applied. After this change the distribution shows a slope where lower values for brk are more common and upper values have about half the frequency of those.

[1] http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/2499/scripts/kernel-security/aslr/

---

I originally posted this to the ARM kernel list and arm64 maintainers, see http://www.spinics.net/lists/arm-kernel/msg502238.html

 arch/arm64/kernel/process.c |   24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

@@ -350,15 +350,27 @@ unsigned long arch_align_stack(unsigned
 	return sp & ~0xf;
 }
 
-static unsigned long randomize_base(unsigned long base)
+unsigned long arch_randomize_brk(struct mm_struct *mm)
 {
+	unsigned long base = mm->brk;
 	unsigned long range_end = base + (STACK_RND_MASK << PAGE_SHIFT) + 1;
-	return randomize_range(base, range_end, 0) ? : base;
-}
+	unsigned long max_stack, range_limit;
 
-unsigned long arch_randomize_brk(struct mm_struct *mm)
-{
-	return randomize_base(mm->brk);
+	/*
+	 * Determine how much room we need to leave available for the stack.
+	 * We limit this to a reasonable value, because extremely large or
+	 * unlimited stacks are always going to bump up against brk at some
+	 * point and we don't want to fail to randomise brk in those cases.
+	 */
+	max_stack = rlimit(RLIMIT_STACK);
+	if (max_stack > SZ_128M)
+		max_stack = SZ_128M;
+
+	range_limit = mm->start_stack - max_stack - 1;
+	if (range_end > range_limit)
+		range_end = range_limit;
+
+	return randomize_range(base, range_end, 0) ? : base;
 }
 
 unsigned long randomize_et_dyn(unsigned long base)

As reported by Guenter Roeck, this patch doesn't compile on 3.14 because it deleted randomize_base which is still used by the macro ELF_ET_DYN_BASE. That use was removed in 3.18 by commit 92980405f353 ("arm64: ASLR: Don't randomise text when randomise_va_space == 0")

Looking at that commit it seems to be what caused the bug $subject patch fixes because it stopped the arm64 implementation putting loaded binaries 2/3rds the way up a task's address range.

So it seems to me, either $subject patch should only be applied to Linux versions 3.18 through 4.0 inclusive; or the fix in commit 92980405f353 also needs backporting to stable kernels before 3.18. (Or some more other solution.)

Either way, it seems $subject patch also needs...

Leaving patch quoted below for reference...

Thanks, I'll just drop this from 3.14-stable, as it doesn't seem to make much sense for it to be backported there.

greg k-h

Early feedback: Commit 'arm64: Make arch_randomize_brk avoid stack area' breaks arm64 builds.

arch/arm64/kernel/process.c: In function �randomize_et_dyn�:
arch/arm64/kernel/process.c:378:9: error: implicit declaration of function �randomize_base�

Guenter

Thanks for the report, I've now dropped it from the tree.

greg k-h

Build results:

	total: 131 pass: 129 fail: 2

Failed builds:
arm64:allnoconfig
arm64:allmodconfig

Qemu test results:

	total: 89 pass: 87 fail: 2

Failed tests:
arm64:smp:defconfig
arm64:nosmp:defconfig

Details are available at http://kerneltests.org/builders.

The failures have already been discussed separately.

Guenter

Thanks for the reports for all of these, this build error should now also be resolved.

greg k-h

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

thanks,
-- Shuah

Thanks for testing and letting me know.

greg k-h

Greg Kroah-Hartman wrote...

Compilation passes again, however the compiled kernel crashes immediately after loading. This happens with a kernel built using gcc5 (5.3.1) only, gcc 4.7 or 4.9 result in a fully working one.

Since kernel 4.6 built using gcc5 runs on that particular hardware (a very old AMD K6 mainboard), I've tried git reverse bisect which left to d34687ab, and me in some confusion.

Very weird, requires more checking.

Christoph

Does 3.14.69 work?

Greg KH wrote...

Neither (if built using gcc5). So do not delay the 3.14.70 release because of my report. The thing that puzzles me: Why did nobody else notice so far? Unless my bisecting went wrong in a very early stage, all versions up to and including 4.4 are affected.

Will do more testing.

Christoph

Thanks, your Interpretation is appreciated :)