3.18.124-stable review

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/codecs/cs4265.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

sound/soc/codecs/cs4265.c +2 -2

@@ -174,8 +174,8 @@ static const struct snd_kcontrol_new cs4
 	SOC_SINGLE("Validity Bit Control Switch", CS4265_SPDIF_CTL2,
 				3, 1, 0),
 	SOC_ENUM("SPDIF Mono/Stereo", spdif_mono_stereo_enum),
-	SOC_SINGLE("MMTLR Data Switch", 0,
-				1, 1, 0),
+	SOC_SINGLE("MMTLR Data Switch", CS4265_SPDIF_CTL2,
+				0, 1, 0),
 	SOC_ENUM("Mono Channel Select", spdif_mono_select_enum),
 	SND_SOC_BYTES("C Data Buffer", CS4265_C_DATA_BUFF, 24),
 };

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #2 lore raw

PATCH 2/120 ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping

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

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

From: Takashi Sakamoto <[email protected]>

commit 493626f2d87a74e6dbea1686499ed6e7e600484e upstream.

When executing 'fw_run_transaction()' with 'TCODE_WRITE_BLOCK_REQUEST', an address of 'payload' argument is used for streaming DMA mapping by 'firewire_ohci' module if 'size' argument is larger than 8 byte. Although in this case the address should not be on kernel stack, current implementation of ALSA bebob driver uses data in kernel stack for a cue to boot M-Audio devices. This often brings unexpected result, especially for a case of CONFIG_VMAP_STACK=y.

This commit fixes the bug.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=201021
Reference: https://forum.manjaro.org/t/firewire-m-audio-410-driver-wont-load-firmware/51165

Fixes a2b2a7798fb6('ALSA: bebob: Send a cue to load firmware for M-Audio Firewire series')

Cc <[email protected]> # v3.16+

Signed-off-by Takashi Sakamoto <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/firewire/bebob/bebob_maudio.c |   24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

sound/firewire/bebob/bebob_maudio.c +14 ~~-10~~

@@ -96,17 +96,13 @@ int snd_bebob_maudio_load_firmware(struc
 	struct fw_device *device = fw_parent_device(unit);
 	int err, rcode;
 	u64 date;
-	__le32 cues[3] = {
-		cpu_to_le32(MAUDIO_BOOTLOADER_CUE1),
-		cpu_to_le32(MAUDIO_BOOTLOADER_CUE2),
-		cpu_to_le32(MAUDIO_BOOTLOADER_CUE3)
-	};
+	__le32 *cues;
 
 	/* check date of software used to build */
 	err = snd_bebob_read_block(unit, INFO_OFFSET_SW_DATE,
 				   &date, sizeof(u64));
 	if (err < 0)
-		goto end;
+		return err;
 	/*
 	 * firmware version 5058 or later has date later than "20070401", but
 	 * 'date' is not null-terminated.

@@ -114,20 +110,28 @@ int snd_bebob_maudio_load_firmware(struc
 	if (date < 0x3230303730343031LL) {
 		dev_err(&unit->device,
 			"Use firmware version 5058 or later\n");
-		err = -ENOSYS;
-		goto end;
+		return -ENXIO;
 	}
 
+	cues = kmalloc_array(3, sizeof(*cues), GFP_KERNEL);
+	if (!cues)
+		return -ENOMEM;
+
+	cues[0] = cpu_to_le32(MAUDIO_BOOTLOADER_CUE1);
+	cues[1] = cpu_to_le32(MAUDIO_BOOTLOADER_CUE2);
+	cues[2] = cpu_to_le32(MAUDIO_BOOTLOADER_CUE3);
+
 	rcode = fw_run_transaction(device->card, TCODE_WRITE_BLOCK_REQUEST,
 				   device->node_id, device->generation,
 				   device->max_speed, BEBOB_ADDR_REG_REQ,
-				   cues, sizeof(cues));
+				   cues, 3 * sizeof(*cues));
+	kfree(cues);
 	if (rcode != RCODE_COMPLETE) {
 		dev_err(&unit->device,
 			"Failed to send a cue to load firmware\n");
 		err = -EIO;
 	}
-end:
+
 	return err;
 }

Greg Kroah-Hartman

author maintainer

2018-10-11 15:33 UTC #3 lore raw

PATCH 3/120 ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO

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

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

From: Willy Tarreau <[email protected]>

commit 49434c6c575d2008c0abbc93e615019f39e01252 upstream.

snd_emu10k1_fx8010_ioctl(SNDRV_EMU10K1_IOCTL_INFO) allocates memory using kmalloc() and partially fills it by calling snd_emu10k1_fx8010_info() before returning the resulting structure to userspace, leaving uninitialized holes. Let's just use kzalloc() here.

BugLink http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html

Signed-off-by Willy Tarreau <[email protected]>

Cc Jann Horn <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/emu10k1/emufx.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/pci/emu10k1/emufx.c +1 -1

@@ -2521,7 +2521,7 @@ static int snd_emu10k1_fx8010_ioctl(stru
 		emu->support_tlv = 1;
 		return put_user(SNDRV_EMU10K1_VERSION, (int __user *)argp);
 	case SNDRV_EMU10K1_IOCTL_INFO:
-		info = kmalloc(sizeof(*info), GFP_KERNEL);
+		info = kzalloc(sizeof(*info), GFP_KERNEL);
 		if (!info)
 			return -ENOMEM;
 		snd_emu10k1_fx8010_info(emu, info);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #4 lore raw

PATCH 4/120 ring-buffer: Allow for rescheduling when removing pages

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

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

From: Vaibhav Nagarnaik <[email protected]>

commit 83f365554e47997ec68dc4eca3f5dce525cd15c3 upstream.

When reducing ring buffer size, pages are removed by scheduling a work item on each CPU for the corresponding CPU ring buffer. After the pages are removed from ring buffer linked list, the pages are free()d in a tight loop. The loop does not give up CPU until all pages are removed. In a worst case behavior, when lot of pages are to be freed, it can cause system stall.

After the pages are removed from the list, the free() can happen while the work is rescheduled. Call cond_resched() in the loop to prevent the system hangup.

Link http://lkml.kernel.org/r/[email protected] open here

Fixes 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic")

Reported-by Jason Behmer <[email protected]>

Signed-off-by Vaibhav Nagarnaik <[email protected]>

Signed-off-by Steven Rostedt (VMware) <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/trace/ring_buffer.c |    2 ++
 1 file changed, 2 insertions(+)

kernel/trace/ring_buffer.c +2 -0

@@ -1542,6 +1542,8 @@ rb_remove_pages(struct ring_buffer_per_c
 	tmp_iter_page = first_page;
 
 	do {
+		cond_resched();
+
 		to_remove_page = tmp_iter_page;
 		rb_inc_page(cpu_buffer, &tmp_iter_page);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #5 lore raw

PATCH 5/120 mm: shmem.c: Correctly annotate new inodes for lockdep

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

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

From: Joel Fernandes (Google) <[email protected]>

commit b45d71fb89ab8adfe727b9d0ee188ed58582a647 upstream.

Directories and inodes don't necessarily need to be in the same lockdep class. For ex, hugetlbfs splits them out too to prevent false positives in lockdep. Annotate correctly after new inode creation. If its a directory inode, it will be put into a different class.

This should fix a lockdep splat reported by syzbot:

Quoted 77 lines

======================================================
WARNING: possible circular locking dependency detected 4.18.0-rc8-next-20180810+ #36 Not tainted
------------------------------------------------------
syz-executor900/4483 is trying to acquire lock:
00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: inode_lock include/linux/fs.h:765 [inline]
00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at:
shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602

but task is already holding lock:
0000000025208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448

which lock already depends on the new lock.

-> #2 (ashmem_mutex){+.+.}:

       __mutex_lock_common kernel/locking/mutex.c:925 [inline]
       __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
       mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
       ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
       call_mmap include/linux/fs.h:1844 [inline]
       mmap_region+0xf27/0x1c50 mm/mmap.c:1762
       do_mmap+0xa10/0x1220 mm/mmap.c:1535
       do_mmap_pgoff include/linux/mm.h:2298 [inline]
       vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
       ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
       __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
       __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
       __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #1 (&mm->mmap_sem){++++}:

       __might_fault+0x155/0x1e0 mm/memory.c:4568
       _copy_to_user+0x30/0x110 lib/usercopy.c:25
       copy_to_user include/linux/uaccess.h:155 [inline]
       filldir+0x1ea/0x3a0 fs/readdir.c:196
       dir_emit_dot include/linux/fs.h:3464 [inline]
       dir_emit_dots include/linux/fs.h:3475 [inline]
       dcache_readdir+0x13a/0x620 fs/libfs.c:193
       iterate_dir+0x48b/0x5d0 fs/readdir.c:51
       __do_sys_getdents fs/readdir.c:231 [inline]
       __se_sys_getdents fs/readdir.c:212 [inline]
       __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #0 (&sb->s_type->i_mutex_key#9){++++}:

       lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
       down_write+0x8f/0x130 kernel/locking/rwsem.c:70
       inode_lock include/linux/fs.h:765 [inline]
       shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
       ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455
       ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:501 [inline]
       do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
       ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
       __do_sys_ioctl fs/ioctl.c:709 [inline]
       __se_sys_ioctl fs/ioctl.c:707 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe

other info that might help us debug this:

Chain exists of:
  &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(ashmem_mutex);
                               lock(&mm->mmap_sem);
                               lock(ashmem_mutex);

Quoted 7 lines

lock(&sb->s_type->i_mutex_key#9);
*** DEADLOCK ***
1 lock held by syz-executor900/4483:
#0: 0000000025208078 (ashmem_mutex){+.+.}, at:
ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Joel Fernandes (Google) <[email protected]>

Reported-by syzbot <[email protected]>

Reviewed-by NeilBrown <[email protected]>

Suggested-by NeilBrown <[email protected]>

Cc Matthew Wilcox <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Hugh Dickins <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 mm/shmem.c |    2 ++
 1 file changed, 2 insertions(+)

mm/shmem.c +2 -0

@@ -1454,6 +1454,8 @@ static struct inode *shmem_get_inode(str
 			mpol_shared_policy_init(&info->policy, NULL);
 			break;
 		}
+
+		lockdep_annotate_inode_mutex_key(inode);
 	} else
 		shmem_free_inode(sb);
 	return inode;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #6 lore raw

PATCH 6/120 gso_segment: Reset skb->mac_len after modifying network header

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

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

From: Toke Høiland-Jørgensen <[email protected]>

[ Upstream commit c56cae23c6b167acc68043c683c4573b80cbcc2c ]

When splitting a GSO segment that consists of encapsulated packets, the skb->mac_len of the segments can end up being set wrong, causing packet drops in particular when using act_mirred and ifb interfaces in combination with a qdisc that splits GSO packets.

This happens because at the time skb_segment() is called, network_header will point to the inner header, throwing off the calculation in skb_reset_mac_len(). The network_header is subsequently adjust by the outer IP gso_segment handlers, but they don't set the mac_len.

Fix this by adding skb_reset_mac_len() calls to both the IPv4 and IPv6 gso_segment handlers, after they modify the network_header.

Many thanks to Eric Dumazet for his help in identifying the cause of the bug.

Acked-by Dave Taht <[email protected]>

Reviewed-by Eric Dumazet <[email protected]>

Signed-off-by Toke Høiland-Jørgensen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ipv4/af_inet.c     |    1 +
 net/ipv6/ip6_offload.c |    1 +
 2 files changed, 2 insertions(+)

net/ipv4/af_inet.c +1 -0

@@ -1288,6 +1288,7 @@ static struct sk_buff *inet_gso_segment(
 		if (encap)
 			skb_reset_inner_headers(skb);
 		skb->network_header = (u8 *)iph - skb->head;
+		skb_reset_mac_len(skb);
 	} while ((skb = skb->next));
 
 out:

net/ipv6/ip6_offload.c +1 -0

@@ -118,6 +118,7 @@ static struct sk_buff *ipv6_gso_segment(
 		ipv6h = (struct ipv6hdr *)(skb_mac_header(skb) + nhoff);
 		ipv6h->payload_len = htons(skb->len - nhoff - sizeof(*ipv6h));
 		skb->network_header = (u8 *)ipv6h - skb->head;
+		skb_reset_mac_len(skb);
 
 		if (udpfrag) {
 			int err = ip6_find_1stfragopt(skb, &prevhdr);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #7 lore raw

PATCH 7/120 net/appletalk: fix minor pointer leak to userspace in SIOCFINDIPDDPRT

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

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

From: Willy Tarreau <[email protected]>

[ Upstream commit 9824dfae5741275473a23a7ed5756c7b6efacc9d ]

Fields ->dev and ->next of struct ipddp_route may be copied to userspace on the SIOCFINDIPDDPRT ioctl. This is only accessible to CAP_NET_ADMIN though. Let's manually copy the relevant fields instead of using memcpy().

BugLink http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html

Cc Jann Horn <[email protected]>

Signed-off-by Willy Tarreau <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/appletalk/ipddp.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

drivers/net/appletalk/ipddp.c +6 -2

@@ -284,8 +284,12 @@ static int ipddp_ioctl(struct net_device
                 case SIOCFINDIPDDPRT:
 			spin_lock_bh(&ipddp_route_lock);
 			rp = __ipddp_find_route(&rcp);
-			if (rp)
-				memcpy(&rcp2, rp, sizeof(rcp2));
+			if (rp) {
+				memset(&rcp2, 0, sizeof(rcp2));
+				rcp2.ip    = rp->ip;
+				rcp2.at    = rp->at;
+				rcp2.flags = rp->flags;
+			}
 			spin_unlock_bh(&ipddp_route_lock);
 
 			if (rp) {

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #8 lore raw

PATCH 8/120 net: hp100: fix always-true check for link up state

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

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

From: Colin Ian King <[email protected]>

[ Upstream commit a7f38002fb69b44f8fc622ecb838665d0b8666af ]

The operation ~(p100_inb(VG_LAN_CFG_1) & HP100_LINK_UP) returns a value that is always non-zero and hence the wait for the link to drop always terminates prematurely. Fix this by using a logical not operator instead of a bitwise complement. This issue has been in the driver since pre-2.6.12-rc2.

Detected by CoverityScan, CID#114157 ("Logical vs. bitwise operator")

Signed-off-by Colin Ian King <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/hp/hp100.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/hp/hp100.c +1 -1

@@ -2637,7 +2637,7 @@ static int hp100_login_to_vg_hub(struct
 		/* Wait for link to drop */
 		time = jiffies + (HZ / 10);
 		do {
-			if (~(hp100_inb(VG_LAN_CFG_1) & HP100_LINK_UP_ST))
+			if (!(hp100_inb(VG_LAN_CFG_1) & HP100_LINK_UP_ST))
 				break;
 			if (!in_interrupt())
 				schedule_timeout_interruptible(1);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #9 lore raw

PATCH 9/120 neighbour: confirm neigh entries when ARP packet is received

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

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

From: Vasily Khoruzhick <[email protected]>

[ Upstream commit f0e0d04413fcce9bc76388839099aee93cd0d33b ]

Update 'confirmed' timestamp when ARP packet is received. It shouldn't affect locktime logic and anyway entry can be confirmed by any higher-layer protocol. Thus it makes sense to confirm it when ARP packet is received.

Fixes 77d7123342dc ("neighbour: update neigh timestamps iff update is effective")

Signed-off-by Vasily Khoruzhick <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/core/neighbour.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

net/core/neighbour.c +8 -5

@@ -1147,6 +1147,12 @@ int neigh_update(struct neighbour *neigh
 		lladdr = neigh->ha;
 	}
 
+	/* Update confirmed timestamp for neighbour entry after we
+	 * received ARP packet even if it doesn't change IP to MAC binding.
+	 */
+	if (new & NUD_CONNECTED)
+		neigh->confirmed = jiffies;
+
 	/* If entry was valid and address is not changed,
 	   do not change entry state, if new one is STALE.
 	 */

@@ -1170,15 +1176,12 @@ int neigh_update(struct neighbour *neigh
 		}
 	}
 
-	/* Update timestamps only once we know we will make a change to the
+	/* Update timestamp only once we know we will make a change to the
 	 * neighbour entry. Otherwise we risk to move the locktime window with
 	 * noop updates and ignore relevant ARP updates.
 	 */
-	if (new != old || lladdr != neigh->ha) {
-		if (new & NUD_CONNECTED)
-			neigh->confirmed = jiffies;
+	if (new != old || lladdr != neigh->ha)
 		neigh->updated = jiffies;
-	}
 
 	if (new != old) {
 		neigh_del_timer(neigh);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #10 lore raw

PATCH 10/120 ipv6: fix possible use-after-free in ip6_xmit()

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

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

From: Eric Dumazet <[email protected]>

[ Upstream commit bbd6528d28c1b8e80832b3b018ec402b6f5c3215 ]

In the unlikely case ip6_xmit() has to call skb_realloc_headroom(), we need to call skb_set_owner_w() before consuming original skb, otherwise we risk a use-after-free.

Bring IPv6 in line with what we do in IPv4 to fix this.

Fixes 1da177e4c3f41 ("Linux-2.6.12-rc2")

Signed-off-by Eric Dumazet <[email protected]>

Reported-by syzbot <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/ipv6/ip6_output.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

net/ipv6/ip6_output.c +2 -1

@@ -183,9 +183,10 @@ int ip6_xmit(struct sock *sk, struct sk_
 				kfree_skb(skb);
 				return -ENOBUFS;
 			}
+			if (skb->sk)
+				skb_set_owner_w(skb2, skb->sk);
 			consume_skb(skb);
 			skb = skb2;
-			skb_set_owner_w(skb, sk);
 		}
 		if (opt->opt_flen)
 			ipv6_push_frag_opts(skb, opt, &proto);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #11 lore raw

PATCH 11/120 scsi: target: iscsi: Use hex2bin instead of a re-implementation

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

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

From: Vincent Pelletier <[email protected]>

commit 1816494330a83f2a064499d8ed2797045641f92c upstream.

This change has the following effects, in order of descreasing importance:

1) Prevent a stack buffer overflow

2) Do not append an unnecessary NULL to an anyway binary buffer, which is writing one byte past client_digest when caller is:
chap_string_to_hex(client_digest, chap_r, strlen(chap_r));

The latter was found by KASAN (see below) when input value hes expected size (32 hex chars), and further analysis revealed a stack buffer overflow can happen when network-received value is longer, allowing an unauthenticated remote attacker to smash up to 17 bytes after destination buffer (16 bytes attacker-controlled and one null). As switching to hex2bin requires specifying destination buffer length, and does not internally append any null, it solves both issues.

This addresses CVE-2018-14633.

Beyond this:

- Validate received value length and check hex2bin accepted the input, to log this rejection reason instead of just failing authentication.

- Only log received CHAP_R and CHAP_C values once they passed sanity checks.

==================================================================

BUG: KASAN: stack-out-of-bounds in chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
Write of size 1 at addr ffff8801090ef7c8 by task kworker/0:0/1021

CPU: 0 PID: 1021 Comm: kworker/0:0 Tainted: G           O      4.17.8kasan.sess.connops+ #2
Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 05/19/2014
Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]
Call Trace:
 dump_stack+0x71/0xac
 print_address_description+0x65/0x22e
 ? chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
 kasan_report.cold.6+0x241/0x2fd
 chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
 chap_server_compute_md5.isra.2+0x2cb/0x860 [iscsi_target_mod]
 ? chap_binaryhex_to_asciihex.constprop.5+0x50/0x50 [iscsi_target_mod]
 ? ftrace_caller_op_ptr+0xe/0xe
 ? __orc_find+0x6f/0xc0
 ? unwind_next_frame+0x231/0x850
 ? kthread+0x1a0/0x1c0
 ? ret_from_fork+0x35/0x40
 ? ret_from_fork+0x35/0x40
 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? deref_stack_reg+0xd0/0xd0
 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? is_module_text_address+0xa/0x11
 ? kernel_text_address+0x4c/0x110
 ? __save_stack_trace+0x82/0x100
 ? ret_from_fork+0x35/0x40
 ? save_stack+0x8c/0xb0
 ? 0xffffffffc1660000
 ? iscsi_target_do_login+0x155/0x8d0 [iscsi_target_mod]
 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? process_one_work+0x35c/0x640
 ? worker_thread+0x66/0x5d0
 ? kthread+0x1a0/0x1c0
 ? ret_from_fork+0x35/0x40
 ? iscsi_update_param_value+0x80/0x80 [iscsi_target_mod]
 ? iscsit_release_cmd+0x170/0x170 [iscsi_target_mod]
 chap_main_loop+0x172/0x570 [iscsi_target_mod]
 ? chap_server_compute_md5.isra.2+0x860/0x860 [iscsi_target_mod]
 ? rx_data+0xd6/0x120 [iscsi_target_mod]
 ? iscsit_print_session_params+0xd0/0xd0 [iscsi_target_mod]
 ? cyc2ns_read_begin.part.2+0x90/0x90
 ? _raw_spin_lock_irqsave+0x25/0x50
 ? memcmp+0x45/0x70
 iscsi_target_do_login+0x875/0x8d0 [iscsi_target_mod]
 ? iscsi_target_check_first_request.isra.5+0x1a0/0x1a0 [iscsi_target_mod]
 ? del_timer+0xe0/0xe0
 ? memset+0x1f/0x40
 ? flush_sigqueue+0x29/0xd0
 iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? iscsi_target_nego_release+0x80/0x80 [iscsi_target_mod]
 ? iscsi_target_restore_sock_callbacks+0x130/0x130 [iscsi_target_mod]
 process_one_work+0x35c/0x640
 worker_thread+0x66/0x5d0
 ? flush_rcu_work+0x40/0x40
 kthread+0x1a0/0x1c0
 ? kthread_bind+0x30/0x30
 ret_from_fork+0x35/0x40

The buggy address belongs to the page:
page:ffffea0004243bc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0x17fffc000000000()
raw: 017fffc000000000 0000000000000000 0000000000000000 00000000ffffffff
raw: ffffea0004243c20 ffffea0004243ba0 0000000000000000 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8801090ef680: f2 f2 f2 f2 f2 f2 f2 01 f2 f2 f2 f2 f2 f2 f2 00
 ffff8801090ef700: f2 f2 f2 f2 f2 f2 f2 00 02 f2 f2 f2 f2 f2 f2 00
>ffff8801090ef780: 00 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2 f2 00
                                              ^
 ffff8801090ef800: 00 f2 f2 f2 f2 f2 f2 00 00 00 00 02 f2 f2 f2 f2
 ffff8801090ef880: f2 f2 f2 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00
==================================================================

Signed-off-by Vincent Pelletier <[email protected]>

Reviewed-by Mike Christie <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/target/iscsi/iscsi_target_auth.c |   30 ++++++++++++++----------------
 1 file changed, 14 insertions(+), 16 deletions(-)

drivers/target/iscsi/iscsi_target_auth.c +14 ~~-16~~

@@ -26,18 +26,6 @@
 #include "iscsi_target_nego.h"
 #include "iscsi_target_auth.h"
 
-static int chap_string_to_hex(unsigned char *dst, unsigned char *src, int len)
-{
-	int j = DIV_ROUND_UP(len, 2), rc;
-
-	rc = hex2bin(dst, src, j);
-	if (rc < 0)
-		pr_debug("CHAP string contains non hex digit symbols\n");
-
-	dst[j] = '\0';
-	return j;
-}
-
 static void chap_binaryhex_to_asciihex(char *dst, char *src, int src_len)
 {
 	int i;

@@ -241,9 +229,16 @@ static int chap_server_compute_md5(
 		pr_err("Could not find CHAP_R.\n");
 		goto out;
 	}
+	if (strlen(chap_r) != MD5_SIGNATURE_SIZE * 2) {
+		pr_err("Malformed CHAP_R\n");
+		goto out;
+	}
+	if (hex2bin(client_digest, chap_r, MD5_SIGNATURE_SIZE) < 0) {
+		pr_err("Malformed CHAP_R\n");
+		goto out;
+	}
 
 	pr_debug("[server] Got CHAP_R=%s\n", chap_r);
-	chap_string_to_hex(client_digest, chap_r, strlen(chap_r));
 
 	tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
 	if (IS_ERR(tfm)) {

@@ -348,9 +343,7 @@ static int chap_server_compute_md5(
 		pr_err("Could not find CHAP_C.\n");
 		goto out;
 	}
-	pr_debug("[server] Got CHAP_C=%s\n", challenge);
-	challenge_len = chap_string_to_hex(challenge_binhex, challenge,
-				strlen(challenge));
+	challenge_len = DIV_ROUND_UP(strlen(challenge), 2);
 	if (!challenge_len) {
 		pr_err("Unable to convert incoming challenge\n");
 		goto out;

@@ -359,6 +352,11 @@ static int chap_server_compute_md5(
 		pr_err("CHAP_C exceeds maximum binary size of 1024 bytes\n");
 		goto out;
 	}
+	if (hex2bin(challenge_binhex, challenge, challenge_len) < 0) {
+		pr_err("Malformed CHAP_C\n");
+		goto out;
+	}
+	pr_debug("[server] Got CHAP_C=%s\n", challenge);
 	/*
 	 * During mutual authentication, the CHAP_C generated by the
 	 * initiator must not match the original CHAP_C generated by

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #12 lore raw

PATCH 12/120 ocfs2: fix ocfs2 read block panic

Link https://oss.oracle.com/pipermail/ocfs2-devel/2013-May/008931.html

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

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

From: Junxiao Bi <[email protected]>

commit 234b69e3e089d850a98e7b3145bd00e9b52b1111 upstream.

While reading block, it is possible that io error return due to underlying storage issue, in this case, BH_NeedsValidate was left in the buffer head. Then when reading the very block next time, if it was already linked into journal, that will trigger the following panic.

[203748.702517] kernel BUG at fs/ocfs2/buffer_head_io.c:342!
[203748.702533] invalid opcode: 0000 [#1] SMP
[203748.702561] Modules linked in: ocfs2 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc dm_switch dm_queue_length dm_multipath bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i iw_cxgb4 cxgb4 cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif i2c_core ipmi_si ipmi_msghandler acpi_pad pcspkr sb_edac edac_core lpc_ich mfd_core shpchp sg tg3 ptp pps_core ext4 jbd2 mbcache2 sr_mod cdrom sd_mod ahci libahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod
[203748.703024] CPU: 7 PID: 38369 Comm: touch Not tainted 4.1.12-124.18.6.el6uek.x86_64 #2
[203748.703045] Hardware name: Dell Inc. PowerEdge R620/0PXXHP, BIOS 2.5.2 01/28/2015
[203748.703067] task: ffff880768139c00 ti: ffff88006ff48000 task.ti: ffff88006ff48000
[203748.703088] RIP: 0010:[<ffffffffa05e9f09>]  [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]
[203748.703130] RSP: 0018:ffff88006ff4b818  EFLAGS: 00010206
[203748.703389] RAX: 0000000008620029 RBX: ffff88006ff4b910 RCX: 0000000000000000
[203748.703885] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000023079fe
[203748.704382] RBP: ffff88006ff4b8d8 R08: 0000000000000000 R09: ffff8807578c25b0
[203748.704877] R10: 000000000f637376 R11: 000000003030322e R12: 0000000000000000
[203748.705373] R13: ffff88006ff4b910 R14: ffff880732fe38f0 R15: 0000000000000000
[203748.705871] FS:  00007f401992c700(0000) GS:ffff880bfebc0000(0000) knlGS:0000000000000000
[203748.706370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[203748.706627] CR2: 00007f4019252440 CR3: 00000000a621e000 CR4: 0000000000060670
[203748.707124] Stack:
[203748.707371]  ffff88006ff4b828 ffffffffa0609f52 ffff88006ff4b838 0000000000000001
[203748.707885]  0000000000000000 0000000000000000 ffff880bf67c3800 ffffffffa05eca00
[203748.708399]  00000000023079ff ffffffff81c58b80 0000000000000000 0000000000000000
[203748.708915] Call Trace:
[203748.709175]  [<ffffffffa0609f52>] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2]
[203748.709680]  [<ffffffffa05eca00>] ? ocfs2_empty_dir_filldir+0x80/0x80 [ocfs2]
[203748.710185]  [<ffffffffa05ec0cb>] ocfs2_read_dir_block_direct+0x3b/0x200 [ocfs2]
[203748.710691]  [<ffffffffa05f0fbf>] ocfs2_prepare_dx_dir_for_insert.isra.57+0x19f/0xf60 [ocfs2]
[203748.711204]  [<ffffffffa065660f>] ? ocfs2_metadata_cache_io_unlock+0x1f/0x30 [ocfs2]
[203748.711716]  [<ffffffffa05f4f3a>] ocfs2_prepare_dir_for_insert+0x13a/0x890 [ocfs2]
[203748.712227]  [<ffffffffa05f442e>] ? ocfs2_check_dir_for_entry+0x8e/0x140 [ocfs2]
[203748.712737]  [<ffffffffa061b2f2>] ocfs2_mknod+0x4b2/0x1370 [ocfs2]
[203748.713003]  [<ffffffffa061c385>] ocfs2_create+0x65/0x170 [ocfs2]
[203748.713263]  [<ffffffff8121714b>] vfs_create+0xdb/0x150
[203748.713518]  [<ffffffff8121b225>] do_last+0x815/0x1210
[203748.713772]  [<ffffffff812192e9>] ? path_init+0xb9/0x450
[203748.714123]  [<ffffffff8121bca0>] path_openat+0x80/0x600
[203748.714378]  [<ffffffff811bcd45>] ? handle_pte_fault+0xd15/0x1620
[203748.714634]  [<ffffffff8121d7ba>] do_filp_open+0x3a/0xb0
[203748.714888]  [<ffffffff8122a767>] ? __alloc_fd+0xa7/0x130
[203748.715143]  [<ffffffff81209ffc>] do_sys_open+0x12c/0x220
[203748.715403]  [<ffffffff81026ddb>] ? syscall_trace_enter_phase1+0x11b/0x180
[203748.715668]  [<ffffffff816f0c9f>] ? system_call_after_swapgs+0xe9/0x190
[203748.715928]  [<ffffffff8120a10e>] SyS_open+0x1e/0x20
[203748.716184]  [<ffffffff816f0d5e>] system_call_fastpath+0x18/0xd7
[203748.716440] Code: 00 00 48 8b 7b 08 48 83 c3 10 45 89 f8 44 89 e1 44 89 f2 4c 89 ee e8 07 06 11 e1 48 8b 03 48 85 c0 75 df 8b 5d c8 e9 4d fa ff ff <0f> 0b 48 8b 7d a0 e8 dc c6 06 00 48 b8 00 00 00 00 00 00 00 10
[203748.717505] RIP  [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2]
[203748.717775]  RSP <ffff88006ff4b818>

Joesph ever reported a similar panic.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Junxiao Bi <[email protected]>

Cc Joseph Qi <[email protected]>

Cc Mark Fasheh <[email protected]>

Cc Joel Becker <[email protected]>

Cc Changwei Ge <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ocfs2/buffer_head_io.c |    1 +
 1 file changed, 1 insertion(+)

fs/ocfs2/buffer_head_io.c +1 -0

@@ -330,6 +330,7 @@ int ocfs2_read_blocks(struct ocfs2_cachi
 				 * for this bh as it's not marked locally
 				 * uptodate. */
 				status = -EIO;
+				clear_buffer_needs_validate(bh);
 				put_bh(bh);
 				bhs[i] = NULL;
 				continue;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #13 lore raw

PATCH 13/120 ext4: avoid divide by zero fault when deleting corrupted inline directories

https://bugzilla.kernel.org/show_bug.cgi?id=200933

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

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

From: Theodore Ts'o <[email protected]>

commit 4d982e25d0bdc83d8c64e66fdeca0b89240b3b85 upstream.

A specially crafted file system can trick empty_inline_dir() into reading past the last valid entry in a inline directory, and then run into the end of xattr marker. This will trigger a divide by zero fault. Fix this by using the size of the inline directory instead of dir->i_size.

Also clean up error reporting in __ext4_check_dir_entry so that the message is clearer and more understandable --- and avoids the division by zero trap if the size passed in is zero. (I'm not sure why we coded it that way in the first place; printing offset % size is actually more confusing and less useful.)

Reported-by Wen Xu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/dir.c    |   20 +++++++++-----------
 fs/ext4/inline.c |    4 +++-
 2 files changed, 12 insertions(+), 12 deletions(-)

fs/ext4/dir.c +9 ~~-11~~

@@ -77,7 +77,7 @@ int __ext4_check_dir_entry(const char *f
 	else if (unlikely(rlen < EXT4_DIR_REC_LEN(de->name_len)))
 		error_msg = "rec_len is too small for name_len";
 	else if (unlikely(((char *) de - buf) + rlen > size))
-		error_msg = "directory entry across range";
+		error_msg = "directory entry overrun";
 	else if (unlikely(le32_to_cpu(de->inode) >
 			le32_to_cpu(EXT4_SB(dir->i_sb)->s_es->s_inodes_count)))
 		error_msg = "inode out of bounds";

@@ -86,18 +86,16 @@ int __ext4_check_dir_entry(const char *f
 
 	if (filp)
 		ext4_error_file(filp, function, line, bh->b_blocknr,
-				"bad entry in directory: %s - offset=%u(%u), "
-				"inode=%u, rec_len=%d, name_len=%d",
-				error_msg, (unsigned) (offset % size),
-				offset, le32_to_cpu(de->inode),
-				rlen, de->name_len);
+				"bad entry in directory: %s - offset=%u, "
+				"inode=%u, rec_len=%d, name_len=%d, size=%d",
+				error_msg, offset, le32_to_cpu(de->inode),
+				rlen, de->name_len, size);
 	else
 		ext4_error_inode(dir, function, line, bh->b_blocknr,
-				"bad entry in directory: %s - offset=%u(%u), "
-				"inode=%u, rec_len=%d, name_len=%d",
-				error_msg, (unsigned) (offset % size),
-				offset, le32_to_cpu(de->inode),
-				rlen, de->name_len);
+				"bad entry in directory: %s - offset=%u, "
+				"inode=%u, rec_len=%d, name_len=%d, size=%d",
+				 error_msg, offset, le32_to_cpu(de->inode),
+				 rlen, de->name_len, size);
 
 	return 1;
 }

fs/ext4/inline.c +3 -1

@@ -1738,6 +1738,7 @@ int empty_inline_dir(struct inode *dir,
 {
 	int err, inline_size;
 	struct ext4_iloc iloc;
+	size_t inline_len;
 	void *inline_pos;
 	unsigned int offset;
 	struct ext4_dir_entry_2 *de;

@@ -1765,8 +1766,9 @@ int empty_inline_dir(struct inode *dir,
 		goto out;
 	}
 
+	inline_len = ext4_get_inline_size(dir);
 	offset = EXT4_INLINE_DOTDOT_SIZE;
-	while (offset < dir->i_size) {
+	while (offset < inline_len) {
 		de = ext4_get_inline_entry(dir, &iloc, offset,
 					   &inline_pos, &inline_size);
 		if (ext4_check_dir_entry(dir, NULL, de,

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #14 lore raw

PATCH 14/120 ext4: recalucate superblock checksum after updating free blocks/inodes

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

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

From: Theodore Ts'o <[email protected]>

commit 4274f516d4bc50648a4d97e4f67ecbd7b65cde4a upstream.

When mounting the superblock, ext4_fill_super() calculates the free blocks and free inodes and stores them in the superblock. It's not strictly necessary, since we don't use them any more, but it's nice to keep them roughly aligned to reality.

Since it's not critical for file system correctness, the code doesn't call ext4_commit_super(). The problem is that it's in ext4_commit_super() that we recalculate the superblock checksum. So if we're not going to call ext4_commit_super(), we need to call ext4_superblock_csum_set() to make sure the superblock checksum is consistent.

Most of the time, this doesn't matter, since we end up calling ext4_commit_super() very soon thereafter, and definitely by the time the file system is unmounted. However, it doesn't work in this sequence:

mke2fs -Fq -t ext4 /dev/vdc 128M
mount /dev/vdc /vdc
cp xfstests/git-versions /vdc
godown /vdc
umount /vdc
mount /dev/vdc
tune2fs -l /dev/vdc

With this commit, the "tune2fs -l" no longer fails.

Reported-by Chengguang Xu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/super.c |    2 ++
 1 file changed, 2 insertions(+)

fs/ext4/super.c +2 -0

@@ -4237,11 +4237,13 @@ no_journal:
 	block = ext4_count_free_clusters(sb);
 	ext4_free_blocks_count_set(sbi->s_es, 
 				   EXT4_C2B(sbi, block));
+	ext4_superblock_csum_set(sb);
 	err = percpu_counter_init(&sbi->s_freeclusters_counter, block,
 				  GFP_KERNEL);
 	if (!err) {
 		unsigned long freei = ext4_count_free_inodes(sb);
 		sbi->s_es->s_free_inodes_count = cpu_to_le32(freei);
+		ext4_superblock_csum_set(sb);
 		err = percpu_counter_init(&sbi->s_freeinodes_counter, freei,
 					  GFP_KERNEL);
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:33 UTC #15 lore raw

PATCH 15/120 ext4: fix online resizes handling of a too-small final block group

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

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

From: Theodore Ts'o <[email protected]>

commit f0a459dec5495a3580f8d784555e6f8f3bf7f263 upstream.

Avoid growing the file system to an extent so that the last block group is too small to hold all of the metadata that must be stored in the block group.

This problem can be triggered with the following reproducer:

umount /mnt

mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \
	-E resize=1073741824 /tmp/foo.img 128M

mount /tmp/foo.img /mnt
truncate --size 1708M /tmp/foo.img
resize2fs /dev/loop0 295400
umount /mnt
e2fsck -fy /tmp/foo.img

Reported-by Torsten Hilbrich <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/resize.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

fs/ext4/resize.c +20 -0

@@ -1957,6 +1957,26 @@ retry:
 		}
 	}
 
+	/*
+	 * Make sure the last group has enough space so that it's
+	 * guaranteed to have enough space for all metadata blocks
+	 * that it might need to hold.  (We might not need to store
+	 * the inode table blocks in the last block group, but there
+	 * will be cases where this might be needed.)
+	 */
+	if ((ext4_group_first_block_no(sb, n_group) +
+	     ext4_group_overhead_blocks(sb, n_group) + 2 +
+	     sbi->s_itb_per_group + sbi->s_cluster_ratio) >= n_blocks_count) {
+		n_blocks_count = ext4_group_first_block_no(sb, n_group);
+		n_group--;
+		n_blocks_count_retry = 0;
+		if (resize_inode) {
+			iput(resize_inode);
+			resize_inode = NULL;
+		}
+		goto retry;
+	}
+
 	/* extend the last group */
 	if (n_group == o_group)
 		add = n_blocks_count - o_blocks_count;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #16 lore raw

PATCH 16/120 ext4: dont mark mmp buffer head dirty

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

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

From: Li Dongyang <[email protected]>

commit fe18d649891d813964d3aaeebad873f281627fbc upstream.

Marking mmp bh dirty before writing it will make writeback pick up mmp block later and submit a write, we don't want the duplicate write as kmmpd thread should have full control of reading and writing the mmp block.
Another reason is we will also have random I/O error on the writeback request when blk integrity is enabled, because kmmpd could modify the content of the mmp block(e.g. setting new seq and time) while the mmp block is under I/O requested by writeback.

Signed-off-by Li Dongyang <[email protected]>

Reviewed-by Andreas Dilger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/mmp.c |    1 -
 1 file changed, 1 deletion(-)

fs/ext4/mmp.c +0 -1

@@ -48,7 +48,6 @@ static int write_mmp_block(struct super_
 	 */
 	sb_start_write(sb);
 	ext4_mmp_csum_set(sb, mmp);
-	mark_buffer_dirty(bh);
 	lock_buffer(bh);
 	bh->b_end_io = end_buffer_write_sync;
 	get_bh(bh);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #17 lore raw

PATCH 17/120 arm64: Add trace_hardirqs_off annotation in ret_to_user

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

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

From: Catalin Marinas <[email protected]>

commit db3899a6477a4dccd26cbfb7f408b6be2cc068e0 upstream.

When a kernel is built with CONFIG_TRACE_IRQFLAGS the following warning is produced when entering userspace for the first time:

  WARNING: at /work/Linux/linux-2.6-aarch64/kernel/locking/lockdep.c:3519
  Modules linked in:
  CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc3+ #639
  Hardware name: Juno (DT)
  task: ffffffc9768a0000 ti: ffffffc9768a8000 task.ti: ffffffc9768a8000
  PC is at check_flags.part.22+0x19c/0x1a8
  LR is at check_flags.part.22+0x19c/0x1a8
  pc : [<ffffffc0000fba6c>] lr : [<ffffffc0000fba6c>] pstate: 600001c5
  sp : ffffffc9768abe10
  x29: ffffffc9768abe10 x28: ffffffc9768a8000
  x27: 0000000000000000 x26: 0000000000000001
  x25: 00000000000000a6 x24: ffffffc00064be6c
  x23: ffffffc0009f249e x22: ffffffc9768a0000
  x21: ffffffc97fea5480 x20: 00000000000001c0
  x19: ffffffc00169a000 x18: 0000005558cc7b58
  x17: 0000007fb78e3180 x16: 0000005558d2e238
  x15: ffffffffffffffff x14: 0ffffffffffffffd
  x13: 0000000000000008 x12: 0101010101010101
  x11: 7f7f7f7f7f7f7f7f x10: fefefefefefeff63
  x9 : 7f7f7f7f7f7f7f7f x8 : 6e655f7371726964
  x7 : 0000000000000001 x6 : ffffffc0001079c4
  x5 : 0000000000000000 x4 : 0000000000000001
  x3 : ffffffc001698438 x2 : 0000000000000000
  x1 : ffffffc9768a0000 x0 : 000000000000002e
  Call trace:
  [<ffffffc0000fba6c>] check_flags.part.22+0x19c/0x1a8
  [<ffffffc0000fc440>] lock_is_held+0x80/0x98
  [<ffffffc00064bafc>] __schedule+0x404/0x730
  [<ffffffc00064be6c>] schedule+0x44/0xb8
  [<ffffffc000085bb0>] ret_to_user+0x0/0x24
  possible reason: unannotated irqs-off.
  irq event stamp: 502169
  hardirqs last  enabled at (502169): [<ffffffc000085a98>] el0_irq_naked+0x1c/0x24
  hardirqs last disabled at (502167): [<ffffffc0000bb3bc>] __do_softirq+0x17c/0x298
  softirqs last  enabled at (502168): [<ffffffc0000bb43c>] __do_softirq+0x1fc/0x298
  softirqs last disabled at (502143): [<ffffffc0000bb830>] irq_exit+0xa0/0xf0

This happens because we disable interrupts in ret_to_user before calling schedule() in work_resched. This patch adds the necessary trace_hardirqs_off annotation.

Signed-off-by Catalin Marinas <[email protected]>

Reported-by Mark Rutland <[email protected]>

Cc Will Deacon <[email protected]>

Signed-off-by Will Deacon <[email protected]>

Cc Guenter Roeck <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/kernel/entry.S |    3 +++
 1 file changed, 3 insertions(+)

arch/arm64/kernel/entry.S +3 -0

@@ -633,6 +633,9 @@ work_pending:
 	bl	do_notify_resume
 	b	ret_to_user
 work_resched:
+#ifdef CONFIG_TRACE_IRQFLAGS
+	bl	trace_hardirqs_off		// the IRQs are off here, inform the tracing code
+#endif
 	bl	schedule
 
 /*

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #18 lore raw

PATCH 18/120 HID: sony: Update device ids

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

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

From: Roderick Colenbrander <[email protected]>

commit cf1015d65d7c8a5504a4c03afb60fb86bff0f032 upstream.

Support additional DS4 model.

Signed-off-by Roderick Colenbrander <[email protected]>

Reviewed-by Benjamin Tissoires <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hid/hid-core.c |    2 ++
 drivers/hid/hid-ids.h  |    1 +
 drivers/hid/hid-sony.c |    4 ++++
 3 files changed, 7 insertions(+)

drivers/hid/hid-core.c +2 -0

@@ -1935,6 +1935,8 @@ static const struct hid_device_id hid_ha
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER) },
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2) },
+	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_STEELSERIES, USB_DEVICE_ID_STEELSERIES_SRWS1) },

drivers/hid/hid-ids.h +1 -0

@@ -846,6 +846,7 @@
 #define USB_DEVICE_ID_SONY_PS3_BDREMOTE		0x0306
 #define USB_DEVICE_ID_SONY_PS3_CONTROLLER	0x0268
 #define USB_DEVICE_ID_SONY_PS4_CONTROLLER	0x05c4
+#define USB_DEVICE_ID_SONY_PS4_CONTROLLER_2	0x09cc
 #define USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER	0x042f
 #define USB_DEVICE_ID_SONY_BUZZ_CONTROLLER		0x0002
 #define USB_DEVICE_ID_SONY_WIRELESS_BUZZ_CONTROLLER	0x1000

drivers/hid/hid-sony.c +4 -0

@@ -2042,6 +2042,10 @@ static const struct hid_device_id sony_d
 		.driver_data = DUALSHOCK4_CONTROLLER_USB },
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER),
 		.driver_data = DUALSHOCK4_CONTROLLER_BT },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2),
+		.driver_data = DUALSHOCK4_CONTROLLER_USB },
+	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2),
+		.driver_data = DUALSHOCK4_CONTROLLER_BT },
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, sony_devices);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #19 lore raw

PATCH 19/120 HID: sony: Support DS4 dongle

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

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

From: Roderick Colenbrander <[email protected]>

commit de66a1a04c25f2560a8dca7a95e2a150b0d5e17e upstream.

Add support for USB based DS4 dongle device, which allows connecting a DS4 through Bluetooth, but hides Bluetooth from the host system.

Signed-off-by Roderick Colenbrander <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hid/hid-core.c |    1 +
 drivers/hid/hid-ids.h  |    1 +
 drivers/hid/hid-sony.c |    2 ++
 3 files changed, 4 insertions(+)

drivers/hid/hid-core.c +1 -0

@@ -1937,6 +1937,7 @@ static const struct hid_device_id hid_ha
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2) },
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_STEELSERIES, USB_DEVICE_ID_STEELSERIES_SRWS1) },

drivers/hid/hid-ids.h +1 -0

@@ -847,6 +847,7 @@
 #define USB_DEVICE_ID_SONY_PS3_CONTROLLER	0x0268
 #define USB_DEVICE_ID_SONY_PS4_CONTROLLER	0x05c4
 #define USB_DEVICE_ID_SONY_PS4_CONTROLLER_2	0x09cc
+#define USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE	0x0ba0
 #define USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER	0x042f
 #define USB_DEVICE_ID_SONY_BUZZ_CONTROLLER		0x0002
 #define USB_DEVICE_ID_SONY_WIRELESS_BUZZ_CONTROLLER	0x1000

drivers/hid/hid-sony.c +2 -0

@@ -2046,6 +2046,8 @@ static const struct hid_device_id sony_d
 		.driver_data = DUALSHOCK4_CONTROLLER_USB },
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_2),
 		.driver_data = DUALSHOCK4_CONTROLLER_BT },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE),
+		.driver_data = DUALSHOCK4_CONTROLLER_USB },
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, sony_devices);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #20 lore raw

PATCH 20/120 crypto: skcipher - Fix -Wstringop-truncation warnings

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

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

From: Stafford Horne <[email protected]>

[ Upstream commit cefd769fd0192c84d638f66da202459ed8ad63ba ]

As of GCC 9.0.0 the build is reporting warnings like:

    crypto/ablkcipher.c: In function ‘crypto_ablkcipher_report’:
    crypto/ablkcipher.c:374:2: warning: ‘strncpy’ specified bound 64 equals destination size [-Wstringop-truncation]
      strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "<default>",
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       sizeof(rblkcipher.geniv));
       ~~~~~~~~~~~~~~~~~~~~~~~~~

This means the strnycpy might create a non null terminated string. Fix this by explicitly performing '\0' termination.

Cc Greg Kroah-Hartman <[email protected]>

Cc Arnd Bergmann <[email protected]>

Cc Max Filippov <[email protected]>

Cc Eric Biggers <[email protected]>

Cc Nick Desaulniers <[email protected]>

Signed-off-by Stafford Horne <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 crypto/ablkcipher.c |    2 ++
 crypto/blkcipher.c  |    1 +
 2 files changed, 3 insertions(+)

crypto/ablkcipher.c +2 -0

@@ -382,6 +382,7 @@ static int crypto_ablkcipher_report(stru
 	strncpy(rblkcipher.type, "ablkcipher", sizeof(rblkcipher.type));
 	strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "<default>",
 		sizeof(rblkcipher.geniv));
+	rblkcipher.geniv[sizeof(rblkcipher.geniv) - 1] = '\0';
 
 	rblkcipher.blocksize = alg->cra_blocksize;
 	rblkcipher.min_keysize = alg->cra_ablkcipher.min_keysize;

@@ -463,6 +464,7 @@ static int crypto_givcipher_report(struc
 	strncpy(rblkcipher.type, "givcipher", sizeof(rblkcipher.type));
 	strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "<built-in>",
 		sizeof(rblkcipher.geniv));
+	rblkcipher.geniv[sizeof(rblkcipher.geniv) - 1] = '\0';
 
 	rblkcipher.blocksize = alg->cra_blocksize;
 	rblkcipher.min_keysize = alg->cra_ablkcipher.min_keysize;

crypto/blkcipher.c +1 -0

@@ -514,6 +514,7 @@ static int crypto_blkcipher_report(struc
 	strncpy(rblkcipher.type, "blkcipher", sizeof(rblkcipher.type));
 	strncpy(rblkcipher.geniv, alg->cra_blkcipher.geniv ?: "<default>",
 		sizeof(rblkcipher.geniv));
+	rblkcipher.geniv[sizeof(rblkcipher.geniv) - 1] = '\0';
 
 	rblkcipher.blocksize = alg->cra_blocksize;
 	rblkcipher.min_keysize = alg->cra_blkcipher.min_keysize;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #21 lore raw

PATCH 21/120 tsl2550: fix lux1_input error in low light

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

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

From: Matt Ranostay <[email protected]>

[ Upstream commit ce054546cc2c26891cefa2f284d90d93b52205de ]

ADC channel 0 photodiode detects both infrared + visible light, but ADC channel 1 just detects infrared. However, the latter is a bit more sensitive in that range so complete darkness or low light causes a error condition in which the chan0 - chan1 is negative that results in a -EAGAIN.

This patch changes the resulting lux1_input sysfs attribute message from "Resource temporarily unavailable" to a user-grokable lux value of 0.

Cc Arnd Bergmann <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Signed-off-by Matt Ranostay <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/tsl2550.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/misc/tsl2550.c +1 -1

@@ -177,7 +177,7 @@ static int tsl2550_calculate_lux(u8 ch0,
 		} else
 			lux = 0;
 	else
-		return -EAGAIN;
+		return 0;
 
 	/* LUX range check */
 	return lux > TSL2550_MAX_LUX ? TSL2550_MAX_LUX : lux;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:33 UTC #22 lore raw

PATCH 22/120 x86/numa_emulation: Fix emulated-to-physical node mapping

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

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

From: Dan Williams <[email protected]>

[ Upstream commit 3b6c62f363a19ce82bf378187ab97c9dc01e3927 ]

Without this change the distance table calculation for emulated nodes may use the wrong numa node and report an incorrect distance.

Signed-off-by Dan Williams <[email protected]>

Cc David Rientjes <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Wei Yang <[email protected]>

Link http://lkml.kernel.org/r/153089328103.27680.14778434392225818887.stgit@dwillia2-desk3.amr.corp.intel.com open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

arch/x86/mm/numa_emulation.c +1 -1

@@ -60,7 +60,7 @@ static int __init emu_setup_memblk(struc
 	eb->nid = nid;
 
 	if (emu_nid_to_phys[nid] == NUMA_NO_NODE)
-		emu_nid_to_phys[nid] = nid;
+		emu_nid_to_phys[nid] = pb->nid;
 
 	pb->start += size;
 	if (pb->start >= pb->end) {

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #23 lore raw

PATCH 23/120 uwb: hwa-rc: fix memory leak at probe

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

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

From: Anton Vasilyev <[email protected]>

[ Upstream commit 11b71782c1d10d9bccc31825cf84291cd7588a1e ]

hwarc_probe() allocates memory for hwarc, but does not free it if uwb_rc_add() or hwarc_get_version() fail.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by Anton Vasilyev <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/uwb/hwa-rc.c |    1 +
 1 file changed, 1 insertion(+)

drivers/uwb/hwa-rc.c +1 -0

@@ -875,6 +875,7 @@ error_get_version:
 error_rc_add:
 	usb_put_intf(iface);
 	usb_put_dev(hwarc->usb_dev);
+	kfree(hwarc);
 error_alloc:
 	uwb_rc_put(uwb_rc);
 error_rc_alloc:

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #24 lore raw

PATCH 24/120 USB: serial: kobil_sct: fix modem-status error handling

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

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

From: Johan Hovold <[email protected]>

[ Upstream commit a420b5d939ee58f1d950f0ea782834056520aeaa ]

Make sure to return -EIO in case of a short modem-status read request.

While at it, split the debug message to not include the (zeroed) transfer-buffer content in case of errors.

Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")

Signed-off-by Johan Hovold <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/serial/kobil_sct.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

drivers/usb/serial/kobil_sct.c +10 -2

@@ -396,12 +396,20 @@ static int kobil_tiocmget(struct tty_str
 			  transfer_buffer_length,
 			  KOBIL_TIMEOUT);
 
-	dev_dbg(&port->dev, "%s - Send get_status_line_state URB returns: %i. Statusline: %02x\n",
-		__func__, result, transfer_buffer[0]);
+	dev_dbg(&port->dev, "Send get_status_line_state URB returns: %i\n",
+			result);
+	if (result < 1) {
+		if (result >= 0)
+			result = -EIO;
+		goto out_free;
+	}
+
+	dev_dbg(&port->dev, "Statusline: %02x\n", transfer_buffer[0]);
 
 	result = 0;
 	if ((transfer_buffer[0] & SUSBCR_GSL_DSR) != 0)
 		result = TIOCM_DSR;
+out_free:
 	kfree(transfer_buffer);
 	return result;
 }

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #25 lore raw

PATCH 25/120 media: exynos4-is: Prevent NULL pointer dereference in __isp_video_try_fmt()

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

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

From: Sylwester Nawrocki <[email protected]>

[ Upstream commit 7c1b9a5aeed91bef98988ac0fcf38c8c1f4f9a3a ]

This patch fixes potential NULL pointer dereference as indicated by the following static checker warning:

drivers/media/platform/exynos4-is/fimc-isp-video.c:408 isp_video_try_fmt_mplane()
error: NULL dereference inside function '__isp_video_try_fmt(isp, &f->fmt.pix_mp, (0))()'.

Fixes 34947b8aebe3: ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver")

Reported-by Dan Carpenter <[email protected]>

Signed-off-by Sylwester Nawrocki <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/platform/exynos4-is/fimc-isp-video.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

drivers/media/platform/exynos4-is/fimc-isp-video.c +8 -3

@@ -389,12 +389,17 @@ static void __isp_video_try_fmt(struct f
 				struct v4l2_pix_format_mplane *pixm,
 				const struct fimc_fmt **fmt)
 {
-	*fmt = fimc_isp_find_format(&pixm->pixelformat, NULL, 2);
+	const struct fimc_fmt *__fmt;
+
+	__fmt = fimc_isp_find_format(&pixm->pixelformat, NULL, 2);
+
+	if (fmt)
+		*fmt = __fmt;
 
 	pixm->colorspace = V4L2_COLORSPACE_SRGB;
 	pixm->field = V4L2_FIELD_NONE;
-	pixm->num_planes = (*fmt)->memplanes;
-	pixm->pixelformat = (*fmt)->fourcc;
+	pixm->num_planes = __fmt->memplanes;
+	pixm->pixelformat = __fmt->fourcc;
 	/*
 	 * TODO: double check with the docmentation these width/height
 	 * constraints are correct.

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #26 lore raw

PATCH 26/120 powerpc/kdump: Handle crashkernel memory reservation failure

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

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

From: Hari Bathini <[email protected]>

[ Upstream commit 8950329c4a64c6d3ca0bc34711a1afbd9ce05657 ]

Memory reservation for crashkernel could fail if there are holes around kdump kernel offset (128M). Fail gracefully in such cases and print an error message.

Signed-off-by Hari Bathini <[email protected]>

Tested-by David Gibson <[email protected]>

Reviewed-by Dave Young <[email protected]>

Signed-off-by Michael Ellerman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kernel/machine_kexec.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

arch/powerpc/kernel/machine_kexec.c +6 -1

@@ -186,7 +186,12 @@ void __init reserve_crashkernel(void)
 			(unsigned long)(crashk_res.start >> 20),
 			(unsigned long)(memblock_phys_mem_size() >> 20));
 
-	memblock_reserve(crashk_res.start, crash_size);
+	if (!memblock_is_region_memory(crashk_res.start, crash_size) ||
+	    memblock_reserve(crashk_res.start, crash_size)) {
+		pr_err("Failed to reserve memory for crashkernel!\n");
+		crashk_res.start = crashk_res.end = 0;
+		return;
+	}
 }
 
 int overlaps_crashkernel(unsigned long start, unsigned long size)

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #27 lore raw

PATCH 27/120 x86/tsc: Add missing header to tsc_msr.c

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

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

From: Andy Shevchenko <[email protected]>

[ Upstream commit dbd0fbc76c77daac08ddd245afdcbade0d506e19 ]

Add a missing header otherwise compiler warns about missed prototype:

CC arch/x86/kernel/tsc_msr.o
arch/x86/kernel/tsc_msr.c:73:15: warning: no previous prototype for ‘cpu_khz_from_msr’ [-Wmissing-prototypes]
unsigned long cpu_khz_from_msr(void)

                 ^~~~~~~~~~~~~~~~

Signed-off-by Andy Shevchenko <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Cc "H. Peter Anvin" <[email protected]>

Cc Pavel Tatashin <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/kernel/tsc_msr.c |    1 +
 1 file changed, 1 insertion(+)

arch/x86/kernel/tsc_msr.c +1 -0

@@ -21,6 +21,7 @@
 #include <asm/setup.h>
 #include <asm/apic.h>
 #include <asm/param.h>
+#include <asm/tsc.h>
 
 /* CPU reference clock frequency: in KHz */
 #define FREQ_83		83200

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #28 lore raw

PATCH 28/120 scsi: target/iscsi: Make iscsit_ta_authentication() respect the output buffer size

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

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

From: Bart Van Assche <[email protected]>

[ Upstream commit 35bea5c84fd13c643cce63f0b5cd4b148f8c901d ]

Fixes e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1")

Signed-off-by Bart Van Assche <[email protected]>

Reviewed-by Mike Christie <[email protected]>

Cc Mike Christie <[email protected]>

Cc Christoph Hellwig <[email protected]>

Cc Hannes Reinecke <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/target/iscsi/iscsi_target_tpg.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/target/iscsi/iscsi_target_tpg.c +1 -2

@@ -651,8 +651,7 @@ int iscsit_ta_authentication(struct iscs
 		none = strstr(buf1, NONE);
 		if (none)
 			goto out;
-		strncat(buf1, ",", strlen(","));
-		strncat(buf1, NONE, strlen(NONE));
+		strlcat(buf1, "," NONE, sizeof(buf1));
 		if (iscsi_update_param_value(param, buf1) < 0)
 			return -EINVAL;
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #29 lore raw

PATCH 29/120 scsi: ibmvscsi: Improve strings handling

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

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

From: Breno Leitao <[email protected]>

[ Upstream commit 1262dc09dc9ae7bf4ad00b6a2c5ed6a6936bcd10 ]

Currently an open firmware property is copied into partition_name variable without keeping a room for \0.

Later one, this variable (partition_name), which is 97 bytes long, is strncpyed into ibmvcsci_host_data->madapter_info->partition_name, which is 96 bytes long, possibly truncating it 'again' and removing the \0.

This patch simply decreases the partition name to 96 and just copy using strlcpy() which guarantees that the string is \0 terminated. I think there is no issue if this there is a truncation in this very first copy, i.e, when the open firmware property is read and copied into the driver for the very first time;

This issue also causes the following warning on GCC 8:

drivers/scsi/ibmvscsi/ibmvscsi.c:281:2: warning: strncpy output may be truncated copying 96 bytes from a string of length 96 [-Wstringop-truncation]
...
inlined from ibmvscsi_probe at drivers/scsi/ibmvscsi/ibmvscsi.c:2221:7:
drivers/scsi/ibmvscsi/ibmvscsi.c:265:3: warning: strncpy specified bound 97 equals destination size [-Wstringop-truncation]

CC Bart Van Assche <[email protected]>

CC Tyrel Datwyler <[email protected]>

Signed-off-by Breno Leitao <[email protected]>

Acked-by Tyrel Datwyler <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/ibmvscsi/ibmvscsi.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/scsi/ibmvscsi/ibmvscsi.c +2 -2

@@ -93,7 +93,7 @@ static int max_requests = IBMVSCSI_MAX_R
 static int max_events = IBMVSCSI_MAX_REQUESTS_DEFAULT + 2;
 static int fast_fail = 1;
 static int client_reserve = 1;
-static char partition_name[97] = "UNKNOWN";
+static char partition_name[96] = "UNKNOWN";
 static unsigned int partition_number = -1;
 
 static struct scsi_transport_template *ibmvscsi_transport_template;

@@ -261,7 +261,7 @@ static void gather_partition_info(void)
 
 	ppartition_name = of_get_property(rootdn, "ibm,partition-name", NULL);
 	if (ppartition_name)
-		strncpy(partition_name, ppartition_name,
+		strlcpy(partition_name, ppartition_name,
 				sizeof(partition_name));
 	p_number_ptr = of_get_property(rootdn, "ibm,partition-no", NULL);
 	if (p_number_ptr)

Greg Kroah-Hartman

author maintainer

2018-10-11 15:36 UTC #30 lore raw

PATCH 30/120 usb: wusbcore: security: cast sizeof to int for comparison

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

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

From: Julia Lawall <[email protected]>

[ Upstream commit d3ac5598c5010a8999978ebbcca3b1c6188ca36b ]

Comparing an int to a size, which is unsigned, causes the int to become unsigned, giving the wrong result. usb_get_descriptor can return a negative error code.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
int x;
expression e,e1;
identifier f;
@@

*x = f(...);
... when != x = e1

    when != if (x < 0 || ...) { ... return ...; }

*x < sizeof(e)
// </smpl>

Signed-off-by Julia Lawall <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/wusbcore/security.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/wusbcore/security.c +1 -1

@@ -230,7 +230,7 @@ int wusb_dev_sec_add(struct wusbhc *wusb
 
 	result = usb_get_descriptor(usb_dev, USB_DT_SECURITY,
 				    0, secd, sizeof(*secd));
-	if (result < sizeof(*secd)) {
+	if (result < (int)sizeof(*secd)) {
 		dev_err(dev, "Can't read security descriptor or "
 			"not enough data: %d\n", result);
 		goto out;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #31 lore raw

PATCH 31/120 alarmtimer: Prevent overflow for relative nanosleep

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

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

From: Thomas Gleixner <[email protected]>

[ Upstream commit 5f936e19cc0ef97dbe3a56e9498922ad5ba1edef ]

Air Icy reported:

  UBSAN: Undefined behaviour in kernel/time/alarmtimer.c:811:7
  signed integer overflow:
  1529859276030040771 + 9223372036854775807 cannot be represented in type 'long long int'
  Call Trace:
   alarm_timer_nsleep+0x44c/0x510 kernel/time/alarmtimer.c:811
   __do_sys_clock_nanosleep kernel/time/posix-timers.c:1235 [inline]
   __se_sys_clock_nanosleep kernel/time/posix-timers.c:1213 [inline]
   __x64_sys_clock_nanosleep+0x326/0x4e0 kernel/time/posix-timers.c:1213
   do_syscall_64+0xb8/0x3a0 arch/x86/entry/common.c:290

alarm_timer_nsleep() uses ktime_add() to add the current time and the relative expiry value. ktime_add() has no sanity checks so the addition can overflow when the relative timeout is large enough.

Use ktime_add_safe() which has the necessary sanity checks in place and limits the result to the valid range.

Fixes 9a7adcf5c6de ("timers: Posix interface for alarm-timers")

Reported-by Team OWL337 <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Cc John Stultz <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/time/alarmtimer.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

kernel/time/alarmtimer.c +2 -1

@@ -776,7 +776,8 @@ static int alarm_timer_nsleep(const cloc
 	/* Convert (if necessary) to absolute time */
 	if (flags != TIMER_ABSTIME) {
 		ktime_t now = alarm_bases[type].gettime();
-		exp = ktime_add(now, exp);
+
+		exp = ktime_add_safe(now, exp);
 	}
 
 	if (alarmtimer_do_nsleep(&alarm, exp))

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #32 lore raw

PATCH 32/120 s390/extmem: fix gcc 8 stringop-overflow warning

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

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

From: Vasily Gorbik <[email protected]>

[ Upstream commit 6b2ddf33baec23dace85bd647e3fc4ac070963e8 ]

arch/s390/mm/extmem.c: In function '__segment_load':
arch/s390/mm/extmem.c:436:2: warning: 'strncat' specified bound 7 equals source length [-Wstringop-overflow=]
strncat(seg->res_name, " (DCSS)", 7);

What gcc complains about here is the misuse of strncat function, which in this case does not limit a number of bytes taken from "src", so it is in the end the same as strcat(seg->res_name, " (DCSS)");

Keeping in mind that a res_name is 15 bytes, strncat in this case would overflow the buffer and write 0 into alignment byte between the fields in the struct. To avoid that increasing res_name size to 16, and reusing strlcat.

Reviewed-by Heiko Carstens <[email protected]>

Signed-off-by Vasily Gorbik <[email protected]>

Signed-off-by Martin Schwidefsky <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/s390/mm/extmem.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/s390/mm/extmem.c +2 -2

@@ -80,7 +80,7 @@ struct qin64 {
 struct dcss_segment {
 	struct list_head list;
 	char dcss_name[8];
-	char res_name[15];
+	char res_name[16];
 	unsigned long start_addr;
 	unsigned long end;
 	atomic_t ref_count;

@@ -445,7 +445,7 @@ __segment_load (char *name, int do_nonsh
 	memcpy(&seg->res_name, seg->dcss_name, 8);
 	EBCASC(seg->res_name, 8);
 	seg->res_name[8] = '\0';
-	strncat(seg->res_name, " (DCSS)", 7);
+	strlcat(seg->res_name, " (DCSS)", sizeof(seg->res_name));
 	seg->res->name = seg->res_name;
 	rc = seg->vm_segtype;
 	if (rc == SEG_TYPE_SC ||

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #33 lore raw

PATCH 33/120 ALSA: snd-aoa: add of_node_put() in error path

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

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

From: Nicholas Mc Guire <[email protected]>

[ Upstream commit 222bce5eb88d1af656419db04bcd84b2419fb900 ]

Both calls to of_find_node_by_name() and of_get_next_child() return a
node pointer with refcount incremented thus it must be explicidly decremented here after the last usage. As we are assured to have a refcounted np either from the initial of_find_node_by_name(NULL, name); or from the of_get_next_child(gpio, np) in the while loop if we reached the error code path below, an x of_node_put(np) is needed.

Signed-off-by Nicholas Mc Guire <[email protected]>

Fixes commit f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/aoa/core/gpio-feature.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

sound/aoa/core/gpio-feature.c +3 -1

@@ -88,8 +88,10 @@ static struct device_node *get_gpio(char
 	}
 
 	reg = of_get_property(np, "reg", NULL);
-	if (!reg)
+	if (!reg) {
+		of_node_put(np);
 		return NULL;
+	}
 
 	*gpioptr = *reg;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #34 lore raw

PATCH 34/120 media: s3c-camif: ignore -ENOIOCTLCMD from v4l2_subdev_call for s_power

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

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

From: Akinobu Mita <[email protected]>

[ Upstream commit 30ed2b83343bd1e07884ca7355dac70d25ffc158 ]

When the subdevice doesn't provide s_power core ops callback, the v4l2_subdev_call for s_power returns -ENOIOCTLCMD. If the subdevice doesn't have the special handling for its power saving mode, the s_power isn't required. So -ENOIOCTLCMD from the v4l2_subdev_call should be ignored.

Cc Hans Verkuil <[email protected]>

Signed-off-by Akinobu Mita <[email protected]>

Acked-by Sylwester Nawrocki <[email protected]>

Signed-off-by Sakari Ailus <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/platform/s3c-camif/camif-capture.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/media/platform/s3c-camif/camif-capture.c +2 -0

@@ -117,6 +117,8 @@ static int sensor_set_power(struct camif
 
 	if (camif->sensor.power_count == !on)
 		err = v4l2_subdev_call(sensor->sd, core, s_power, on);
+	if (err == -ENOIOCTLCMD)
+		err = 0;
 	if (!err)
 		sensor->power_count += on ? 1 : -1;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #35 lore raw

PATCH 35/120 media: soc_camera: ov772x: correct setting of banding filter

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

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

From: Akinobu Mita <[email protected]>

[ Upstream commit 22216ec41e919682c15345e95928f266e8ba6f9e ]

The banding filter ON/OFF is controlled via bit 5 of COM8 register. It is attempted to be enabled in ov772x_set_params() by the following line.

	ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, 1);

But this unexpectedly results disabling the banding filter, because the mask and set bits are exclusive.

On the other hand, ov772x_s_ctrl() correctly sets the bit by:

	ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, BNDF_ON_OFF);

The same fix was already applied to non-soc_camera version of ov772x driver in the commit commit a024ee14cd36 ("media: ov772x: correct setting of banding filter")

Cc Jacopo Mondi <[email protected]>

Cc Laurent Pinchart <[email protected]>

Cc Hans Verkuil <[email protected]>

Signed-off-by Akinobu Mita <[email protected]>

Signed-off-by Sakari Ailus <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/i2c/soc_camera/ov772x.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/media/i2c/soc_camera/ov772x.c +1 -1

@@ -834,7 +834,7 @@ static int ov772x_set_params(struct ov77
 	 * set COM8
 	 */
 	if (priv->band_filter) {
-		ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, 1);
+		ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, BNDF_ON_OFF);
 		if (!ret)
 			ret = ov772x_mask_set(client, BDBASE,
 					      0xff, 256 - priv->band_filter);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #36 lore raw

PATCH 36/120 staging: android: ashmem: Fix mmap size validation

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

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

From: Alistair Strachan <[email protected]>

[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]

The ashmem driver did not check that the size/offset of the vma passed to its .mmap() function was not larger than the ashmem object being mapped. This could cause mmap() to succeed, even though accessing parts of the mapping would later fail with a segmentation fault.

Ensure an error is returned by the ashmem_mmap() function if the vma size is larger than the ashmem object size. This enables safer handling of the problem in userspace.

Cc Todd Kjos <[email protected]>

Cc Joel Fernandes <[email protected]>

Signed-off-by Alistair Strachan <[email protected]>

Acked-by Joel Fernandes (Google) <[email protected]>

Reviewed-by Martijn Coenen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/staging/android/ashmem.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/staging/android/ashmem.c +6 -0

@@ -370,6 +370,12 @@ static int ashmem_mmap(struct file *file
 		goto out;
 	}
 
+	/* requested mapping size larger than object size */
+	if (vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size)) {
+		ret = -EINVAL;
+		goto out;
+	}
+
 	/* requested protection bits must match our allowed protection mask */
 	if (unlikely((vma->vm_flags & ~calc_vm_prot_bits(asma->prot_mask)) &
 		     calc_vm_prot_bits(PROT_MASK))) {

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #37 lore raw

PATCH 37/120 drivers/tty: add error handling for pcmcia_loop_config

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

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

From: Zhouyang Jia <[email protected]>

[ Upstream commit 85c634e919bd6ef17427f26a52920aeba12e16ee ]

When pcmcia_loop_config fails, the lack of error-handling code may cause unexpected results.

This patch adds error-handling code after calling pcmcia_loop_config.

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/8250/serial_cs.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/tty/serial/8250/serial_cs.c +4 -2

@@ -629,8 +629,10 @@ static int serial_config(struct pcmcia_d
 	    (link->has_func_id) &&
 	    (link->socket->pcmcia_pfc == 0) &&
 	    ((link->func_id == CISTPL_FUNCID_MULTI) ||
-	     (link->func_id == CISTPL_FUNCID_SERIAL)))
-		pcmcia_loop_config(link, serial_check_for_multi, info);
+	     (link->func_id == CISTPL_FUNCID_SERIAL))) {
+		if (pcmcia_loop_config(link, serial_check_for_multi, info))
+			goto failed;
+	}
 
 	/*
 	 * Apply any multi-port quirk.

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #38 lore raw

PATCH 38/120 media: tm6000: add error handling for dvb_register_adapter

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

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

From: Zhouyang Jia <[email protected]>

[ Upstream commit e95d7c6eb94c634852eaa5ff4caf3db05b5d2e86 ]

When dvb_register_adapter fails, the lack of error-handling code may cause unexpected results.

This patch adds error-handling code after calling dvb_register_adapter.

[[email protected]: use pr_err and fix typo: adater -> adapter]

Signed-off-by Hans Verkuil <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/usb/tm6000/tm6000-dvb.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/media/usb/tm6000/tm6000-dvb.c +5 -0

@@ -275,6 +275,11 @@ static int register_dvb(struct tm6000_co
 
 	ret = dvb_register_adapter(&dvb->adapter, "Trident TVMaster 6000 DVB-T",
 					THIS_MODULE, &dev->udev->dev, adapter_nr);
+	if (ret < 0) {
+		pr_err("tm6000: couldn't register the adapter!\n");
+		goto err;
+	}
+
 	dvb->adapter.priv = dev;
 
 	if (dvb->frontend) {

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #39 lore raw

PATCH 39/120 ALSA: hda: Add AZX_DCAPS_PM_RUNTIME for AMD Raven Ridge

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

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

From: Kai-Heng Feng <[email protected]>

[ Upstream commit 1adca4b0cd65c14cb8b8c9c257720385869c3d5f ]

This patch can make audio controller in AMD Raven Ridge gets runtime suspended to D3, to save ~1W power when it's not in use.

Cc Vijendar Mukunda <[email protected]>

Signed-off-by Kai-Heng Feng <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/pci/hda/hda_intel.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

sound/pci/hda/hda_intel.c +2 -1

@@ -2094,7 +2094,8 @@ static const struct pci_device_id azx_id
 	  .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
 	/* AMD Raven */
 	{ PCI_DEVICE(0x1022, 0x15e3),
-	  .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
+	  .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB |
+			 AZX_DCAPS_PM_RUNTIME },
 	/* ATI HDMI */
 	{ PCI_DEVICE(0x1002, 0x0002),
 	  .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS },

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #40 lore raw

PATCH 40/120 rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit ae636fb1554833ee5133ca47bf4b2791b6739c52 ]

This is a static checker fix, not something I have tested. The issue is that on the second iteration through the loop, we jump forward by le32_to_cpu(auth_req->length) bytes. The problem is that if the length is more than "buflen" then we end up with a negative "buflen". A negative buflen is type promoted to a high positive value and the loop continues but it's accessing beyond the end of the buffer.

I believe the "auth_req->length" comes from the firmware and if the firmware is malicious or buggy, you're already toasted so the impact of this bug is probably not very severe.

Fixes 030645aceb3d ("rndis_wlan: handle 802.11 indications from device")

Signed-off-by Dan Carpenter <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/rndis_wlan.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/net/wireless/rndis_wlan.c +2 -0

@@ -2919,6 +2919,8 @@ static void rndis_wlan_auth_indication(s
 
 	while (buflen >= sizeof(*auth_req)) {
 		auth_req = (void *)buf;
+		if (buflen < le32_to_cpu(auth_req->length))
+			return;
 		type = "unknown";
 		flags = le32_to_cpu(auth_req->flags);
 		pairwise_error = false;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #41 lore raw

PATCH 41/120 wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()

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

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

From: Tony Lindgren <[email protected]>

[ Upstream commit 4ec7cece87b3ed21ffcd407c62fb2f151a366bc1 ]

Otherwise we can get:

WARNING: CPU: 0 PID: 55 at drivers/net/wireless/ti/wlcore/io.h:84

I've only seen this few times with the runtime PM patches enabled so this one is probably not needed before that. This seems to work currently based on the current PM implementation timer. Let's apply this separately though in case others are hitting this issue.

Signed-off-by Tony Lindgren <[email protected]>

Signed-off-by Kalle Valo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/wireless/ti/wlcore/cmd.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/net/wireless/ti/wlcore/cmd.c +6 -0

@@ -35,6 +35,7 @@
 #include "wl12xx_80211.h"
 #include "cmd.h"
 #include "event.h"
+#include "ps.h"
 #include "tx.h"
 #include "hw_ops.h"

@@ -187,6 +188,10 @@ int wlcore_cmd_wait_for_event_or_timeout
 
 	timeout_time = jiffies + msecs_to_jiffies(WL1271_EVENT_TIMEOUT);
 
+	ret = wl1271_ps_elp_wakeup(wl);
+	if (ret < 0)
+		return ret;
+
 	do {
 		if (time_after(jiffies, timeout_time)) {
 			wl1271_debug(DEBUG_CMD, "timeout waiting for event %d",

@@ -218,6 +223,7 @@ int wlcore_cmd_wait_for_event_or_timeout
 	} while (!event);
 
 out:
+	wl1271_ps_elp_sleep(wl);
 	kfree(events_vector);
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #42 lore raw

PATCH 42/120 ARM: mvebu: declare asm symbols as character arrays in pmsu.c

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

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

From: Ethan Tuttle <[email protected]>

[ Upstream commit d0d378ff451a66e486488eec842e507d28145813 ]

With CONFIG_FORTIFY_SOURCE, memcpy uses the declared size of operands to detect buffer overflows. If src or dest is declared as a char, attempts to copy more than byte will result in a fortify_panic().

Address this problem in mvebu_setup_boot_addr_wa() by declaring mvebu_boot_wa_start and mvebu_boot_wa_end as character arrays. Also remove a couple addressof operators to avoid "arithmetic on pointer to an incomplete type" compiler error.

See commit 54a7d50b9205 ("x86: mark kprobe templates as character arrays, not single characters") for a similar fix.

Fixes "detected buffer overflow in memcpy" error during init on some mvebu systems (armada-370-xp, armada-375):

(fortify_panic) from (mvebu_setup_boot_addr_wa+0xb0/0xb4) (mvebu_setup_boot_addr_wa) from (mvebu_v7_cpu_pm_init+0x154/0x204) (mvebu_v7_cpu_pm_init) from (do_one_initcall+0x7c/0x1a8) (do_one_initcall) from (kernel_init_freeable+0x1bc/0x254) (kernel_init_freeable) from (kernel_init+0x8/0x114) (kernel_init) from (ret_from_fork+0x14/0x2c)

Signed-off-by Ethan Tuttle <[email protected]>

Tested-by Ethan Tuttle <[email protected]>

Signed-off-by Gregory CLEMENT <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm/mach-mvebu/pmsu.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm/mach-mvebu/pmsu.c +3 -3

@@ -117,8 +117,8 @@ void mvebu_pmsu_set_cpu_boot_addr(int hw
 		PMSU_BOOT_ADDR_REDIRECT_OFFSET(hw_cpu));
 }
 
-extern unsigned char mvebu_boot_wa_start;
-extern unsigned char mvebu_boot_wa_end;
+extern unsigned char mvebu_boot_wa_start[];
+extern unsigned char mvebu_boot_wa_end[];
 
 /*
  * This function sets up the boot address workaround needed for SMP

@@ -131,7 +131,7 @@ int mvebu_setup_boot_addr_wa(unsigned in
 			     phys_addr_t resume_addr_reg)
 {
 	void __iomem *sram_virt_base;
-	u32 code_len = &mvebu_boot_wa_end - &mvebu_boot_wa_start;
+	u32 code_len = mvebu_boot_wa_end - mvebu_boot_wa_start;
 
 	mvebu_mbus_del_window(BOOTROM_BASE, BOOTROM_SIZE);
 	mvebu_mbus_add_window_by_id(crypto_eng_target, crypto_eng_attribute,

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #43 lore raw

PATCH 43/120 HID: hid-ntrig: add error handling for sysfs_create_group

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

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

From: Zhouyang Jia <[email protected]>

[ Upstream commit 44d4d51de9a3534a2b63d69efda02a10e66541e4 ]

When sysfs_create_group fails, the lack of error-handling code may cause unexpected results.

This patch adds error-handling code after calling sysfs_create_group.

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hid/hid-ntrig.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/hid/hid-ntrig.c +2 -0

@@ -953,6 +953,8 @@ static int ntrig_probe(struct hid_device
 
 	ret = sysfs_create_group(&hdev->dev.kobj,
 			&ntrig_attribute_group);
+	if (ret)
+		hid_err(hdev, "cannot create sysfs group\n");
 
 	return 0;
 err_free:

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #44 lore raw

PATCH 44/120 scsi: bnx2i: add error handling for ioremap_nocache

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

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

From: Zhouyang Jia <[email protected]>

[ Upstream commit aa154ea885eb0c2407457ce9c1538d78c95456fa ]

When ioremap_nocache fails, the lack of error-handling code may cause unexpected results.

This patch adds error-handling code after calling ioremap_nocache.

Reviewed-by Johannes Thumshirn <[email protected]>

Acked-by Manish Rangankar <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/bnx2i/bnx2i_hwi.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/scsi/bnx2i/bnx2i_hwi.c +2 -0

@@ -2742,6 +2742,8 @@ int bnx2i_map_ep_dbell_regs(struct bnx2i
 					      BNX2X_DOORBELL_PCI_BAR);
 		reg_off = (1 << BNX2X_DB_SHIFT) * (cid_num & 0x1FFFF);
 		ep->qp.ctx_base = ioremap_nocache(reg_base + reg_off, 4);
+		if (!ep->qp.ctx_base)
+			return -ENOMEM;
 		goto arm_cq;
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #45 lore raw

PATCH 45/120 ASoC: dapm: Fix potential DAI widget pointer deref when linking DAIs

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

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

From: Liam Girdwood <[email protected]>

[ Upstream commit e01b4f624278d5efe5fb5da585ca371947b16680 ]

Sometime a component or topology may configure a DAI widget with no private data leading to a dev_dbg() dereferencne of this data.

Fix this to check for non NULL private data and let users know if widget is missing DAI.

Signed-off-by Liam Girdwood <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 sound/soc/soc-dapm.c |    7 +++++++
 1 file changed, 7 insertions(+)

sound/soc/soc-dapm.c +7 -0

@@ -3400,6 +3400,13 @@ int snd_soc_dapm_link_dai_widgets(struct
 			continue;
 		}
 
+		/* let users know there is no DAI to link */
+		if (!dai_w->priv) {
+			dev_dbg(card->dev, "dai widget %s has no DAI\n",
+				dai_w->name);
+			continue;
+		}
+
 		dai = dai_w->priv;
 
 		/* ...find all widgets with the same stream and link them */

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #46 lore raw

PATCH 46/120 module: exclude SHN_UNDEF symbols from kallsyms api

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

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

From: Jessica Yu <[email protected]>

[ Upstream commit 9f2d1e68cf4d641def734adaccfc3823d3575e6c ]

Livepatch modules are special in that we preserve their entire symbol tables in order to be able to apply relocations after module load. The unwanted side effect of this is that undefined (SHN_UNDEF) symbols of livepatch modules are accessible via the kallsyms api and this can confuse symbol resolution in livepatch (klp_find_object_symbol()) and cause subtle bugs in livepatch.

Have the module kallsyms api skip over SHN_UNDEF symbols. These symbols are usually not available for normal modules anyway as we cut down their symbol tables to just the core (non-undefined) symbols, so this should really just affect livepatch modules. Note that this patch doesn't affect the display of undefined symbols in /proc/kallsyms.

Reported-by Josh Poimboeuf <[email protected]>

Tested-by Josh Poimboeuf <[email protected]>

Reviewed-by Josh Poimboeuf <[email protected]>

Signed-off-by Jessica Yu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 kernel/module.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

kernel/module.c +5 -1

@@ -3592,7 +3592,7 @@ static unsigned long mod_find_symname(st
 
 	for (i = 0; i < kallsyms->num_symtab; i++)
 		if (strcmp(name, symname(kallsyms, i)) == 0 &&
-		    kallsyms->symtab[i].st_info != 'U')
+		    kallsyms->symtab[i].st_shndx != SHN_UNDEF)
 			return kallsyms->symtab[i].st_value;
 	return 0;
 }

@@ -3636,6 +3636,10 @@ int module_kallsyms_on_each_symbol(int (
 		if (mod->state == MODULE_STATE_UNFORMED)
 			continue;
 		for (i = 0; i < kallsyms->num_symtab; i++) {
+
+			if (kallsyms->symtab[i].st_shndx == SHN_UNDEF)
+				continue;
+
 			ret = fn(data, symname(kallsyms, i),
 				 mod, kallsyms->symtab[i].st_value);
 			if (ret != 0)

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #47 lore raw

PATCH 47/120 nfsd: fix corrupted reply to badly ordered compound

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

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

From: "J. Bruce Fields" <[email protected]>

[ Upstream commit 5b7b15aee641904ae269be9846610a3950cbd64c ]

We're encoding a single op in the reply but leaving the number of ops zero, so the reply makes no sense.

Somewhat academic as this isn't a case any real client will hit, though in theory perhaps that could change in a future protocol extension.

Reviewed-by Jeff Layton <[email protected]>

Signed-off-by J. Bruce Fields <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/nfsd/nfs4proc.c |    1 +
 1 file changed, 1 insertion(+)

fs/nfsd/nfs4proc.c +1 -0

@@ -1347,6 +1347,7 @@ nfsd4_proc_compound(struct svc_rqst *rqs
 	if (status) {
 		op = &args->ops[0];
 		op->status = status;
+		resp->opcnt = 1;
 		goto encode_op;
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:37 UTC #48 lore raw

PATCH 48/120 floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl

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

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

From: Andy Whitcroft <[email protected]>

commit 65eea8edc315589d6c993cf12dbb5d0e9ef1fe4e upstream.

The final field of a floppy_struct is the field "name", which is a pointer to a string in kernel memory. The kernel pointer should not be copied to user memory. The FDGETPRM ioctl copies a floppy_struct to user memory, including this "name" field. This pointer cannot be used by the user and it will leak a kernel address to user-space, which will reveal the location of kernel code and data and undermine KASLR protection.

Model this code after the compat ioctl which copies the returned data to a previously cleared temporary structure on the stack (excluding the name pointer) and copy out to userspace from there. As we already have an inparam union with an appropriate member and that memory is already cleared even for read only calls make use of that as a temporary store.

Based on an initial patch by Brian Belleville.

CVE-2018-7755

Signed-off-by Andy Whitcroft <[email protected]>

Broke up long line.

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/block/floppy.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/block/floppy.c +3 -0

@@ -3459,6 +3459,9 @@ static int fd_locked_ioctl(struct block_
 					  (struct floppy_struct **)&outparam);
 		if (ret)
 			return ret;
+		memcpy(&inparam.g, outparam,
+				offsetof(struct floppy_struct, name));
+		outparam = &inparam.g;
 		break;
 	case FDMSGON:
 		UDP->flags |= FTD_MSG;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:33 UTC #49 lore raw

PATCH 49/120 serial: cpm_uart: return immediately from console poll

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

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

From: Christophe Leroy <[email protected]>

commit be28c1e3ca29887e207f0cbcd294cefe5074bab6 upstream.

kgdb expects poll function to return immediately and returning NO_POLL_CHAR when no character is available.

Fixes f5316b4aea024 ("kgdb,8250,pl011: Return immediately from console poll")

Cc Jason Wessel <[email protected]>

Signed-off-by Christophe Leroy <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/tty/serial/cpm_uart/cpm_uart_core.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

drivers/tty/serial/cpm_uart/cpm_uart_core.c +7 -3

@@ -1054,8 +1054,8 @@ static int poll_wait_key(char *obuf, str
 	/* Get the address of the host memory buffer.
 	 */
 	bdp = pinfo->rx_cur;
-	while (bdp->cbd_sc & BD_SC_EMPTY)
-		;
+	if (bdp->cbd_sc & BD_SC_EMPTY)
+		return NO_POLL_CHAR;
 
 	/* If the buffer address is in the CPM DPRAM, don't
 	 * convert it.

@@ -1089,7 +1089,11 @@ static int cpm_get_poll_char(struct uart
 		poll_chars = 0;
 	}
 	if (poll_chars <= 0) {
-		poll_chars = poll_wait_key(poll_buf, pinfo);
+		int ret = poll_wait_key(poll_buf, pinfo);
+
+		if (ret == NO_POLL_CHAR)
+			return ret;
+		poll_chars = ret;
 		pollp = poll_buf;
 	}
 	poll_chars--;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #50 lore raw

PATCH 50/120 spi: tegra20-slink: explicitly enable/disable clock

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

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

From: Marcel Ziswiler <[email protected]>

commit 7001cab1dabc0b72b2b672ef58a90ab64f5e2343 upstream.

Depending on the SPI instance one may get an interrupt storm upon requesting resp. interrupt unless the clock is explicitly enabled beforehand. This has been observed trying to bring up instance 4 on T20.

Signed-off-by Marcel Ziswiler <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/spi/spi-tegra20-slink.c |   31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

drivers/spi/spi-tegra20-slink.c +23 -8

@@ -1063,6 +1063,24 @@ static int tegra_slink_probe(struct plat
 		goto exit_free_master;
 	}
 
+	/* disabled clock may cause interrupt storm upon request */
+	tspi->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(tspi->clk)) {
+		ret = PTR_ERR(tspi->clk);
+		dev_err(&pdev->dev, "Can not get clock %d\n", ret);
+		goto exit_free_master;
+	}
+	ret = clk_prepare(tspi->clk);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Clock prepare failed %d\n", ret);
+		goto exit_free_master;
+	}
+	ret = clk_enable(tspi->clk);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Clock enable failed %d\n", ret);
+		goto exit_free_master;
+	}
+
 	spi_irq = platform_get_irq(pdev, 0);
 	tspi->irq = spi_irq;
 	ret = request_threaded_irq(tspi->irq, tegra_slink_isr,

@@ -1071,14 +1089,7 @@ static int tegra_slink_probe(struct plat
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Failed to register ISR for IRQ %d\n",
 					tspi->irq);
-		goto exit_free_master;
-	}
-
-	tspi->clk = devm_clk_get(&pdev->dev, NULL);
-	if (IS_ERR(tspi->clk)) {
-		dev_err(&pdev->dev, "can not get clock\n");
-		ret = PTR_ERR(tspi->clk);
-		goto exit_free_irq;
+		goto exit_clk_disable;
 	}
 
 	tspi->rst = devm_reset_control_get(&pdev->dev, "spi");

@@ -1138,6 +1149,8 @@ exit_rx_dma_free:
 	tegra_slink_deinit_dma_param(tspi, true);
 exit_free_irq:
 	free_irq(spi_irq, tspi);
+exit_clk_disable:
+	clk_disable(tspi->clk);
 exit_free_master:
 	spi_master_put(master);
 	return ret;

@@ -1150,6 +1163,8 @@ static int tegra_slink_remove(struct pla
 
 	free_irq(tspi->irq, tspi);
 
+	clk_disable(tspi->clk);
+
 	if (tspi->tx_dma_chan)
 		tegra_slink_deinit_dma_param(tspi, false);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #51 lore raw

PATCH 51/120 spi: sh-msiof: Fix handling of write value for SISTR register

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

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

From: Hiromitsu Yamasaki <[email protected]>

commit 31a5fae4c5a009898da6d177901d5328051641ff upstream.

This patch changes writing to the SISTR register according to the H/W user's manual.

The TDREQ bit and RDREQ bits of SISTR are read-only, and must be written their initial values of zero.

Signed-off-by Hiromitsu Yamasaki <[email protected]>

[geert: reword]

Signed-off-by Geert Uytterhoeven <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/spi/spi-sh-msiof.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/spi/spi-sh-msiof.c +2 -1

@@ -332,7 +332,8 @@ static void sh_msiof_spi_set_mode_regs(s
 
 static void sh_msiof_reset_str(struct sh_msiof_spi_priv *p)
 {
-	sh_msiof_write(p, STR, sh_msiof_read(p, STR));
+	sh_msiof_write(p, STR,
+		       sh_msiof_read(p, STR) & ~(STR_TDREQ | STR_RDREQ));
 }
 
 static void sh_msiof_spi_write_fifo_8(struct sh_msiof_spi_priv *p,

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #52 lore raw

PATCH 52/120 spi: rspi: Fix interrupted DMA transfers

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

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

From: Geert Uytterhoeven <[email protected]>

commit 8dbbaa47b96f6ea5f09f922b4effff3c505cd8cf upstream.

When interrupted, wait_event_interruptible_timeout() returns -ERESTARTSYS, and the SPI transfer in progress will fail, as expected:

m25p80 spi0.0: SPI transfer failed: -512 spi_master spi0: failed to transfer one message from queue

However, as the underlying DMA transfers may not have completed, all subsequent SPI transfers may start to fail:

spi_master spi0: receive timeout qspi_transfer_out_in() returned -110
m25p80 spi0.0: SPI transfer failed: -110 spi_master spi0: failed to transfer one message from queue

Fix this by calling dmaengine_terminate_all() not only for timeouts, but also for errors.

This can be reproduced on r8a7991/koelsch, using "hd /dev/mtd0" followed by CTRL-C.

Signed-off-by Geert Uytterhoeven <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/spi/spi-rspi.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

drivers/spi/spi-rspi.c +6 -4

@@ -538,11 +538,13 @@ static int rspi_dma_transfer(struct rspi
 
 	ret = wait_event_interruptible_timeout(rspi->wait,
 					       rspi->dma_callbacked, HZ);
-	if (ret > 0 && rspi->dma_callbacked)
+	if (ret > 0 && rspi->dma_callbacked) {
 		ret = 0;
-	else if (!ret) {
-		dev_err(&rspi->master->dev, "DMA timeout\n");
-		ret = -ETIMEDOUT;
+	} else {
+		if (!ret) {
+			dev_err(&rspi->master->dev, "DMA timeout\n");
+			ret = -ETIMEDOUT;
+		}
 		if (tx)
 			dmaengine_terminate_all(rspi->master->dma_tx);
 		if (rx)

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #53 lore raw

PATCH 53/120 USB: fix error handling in usb_driver_claim_interface()

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

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

From: Alan Stern <[email protected]>

commit bd729f9d67aa9a303d8925bb8c4f06af25f407d1 upstream.

The syzbot fuzzing project found a use-after-free bug in the USB core. The bug was caused by usbfs not unbinding from an interface when the USB device file was closed, which led another process to attempt the unbind later on, after the private data structure had been deallocated.

The reason usbfs did not unbind the interface at the appropriate time was because it thought the interface had never been claimed in the first place. This was caused by the fact that usb_driver_claim_interface() does not clean up properly when device_bind_driver() returns an error. Although the error code gets passed back to the caller, the iface->dev.driver pointer remains set and iface->condition remains equal to USB_INTERFACE_BOUND.

This patch adds proper error handling to usb_driver_claim_interface().

Signed-off-by Alan Stern <[email protected]>

Reported-by [email protected]

CC <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/driver.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

drivers/usb/core/driver.c +15 -0

@@ -555,6 +555,21 @@ int usb_driver_claim_interface(struct us
 	if (!lpm_disable_error)
 		usb_unlocked_enable_lpm(udev);
 
+	if (retval) {
+		dev->driver = NULL;
+		usb_set_intfdata(iface, NULL);
+		iface->needs_remote_wakeup = 0;
+		iface->condition = USB_INTERFACE_UNBOUND;
+
+		/*
+		 * Unbound interfaces are always runtime-PM-disabled
+		 * and runtime-PM-suspended
+		 */
+		if (driver->supports_autosuspend)
+			pm_runtime_disable(dev);
+		pm_runtime_set_suspended(dev);
+	}
+
 	return retval;
 }
 EXPORT_SYMBOL_GPL(usb_driver_claim_interface);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #54 lore raw

PATCH 54/120 USB: handle NULL config in usb_find_alt_setting()

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

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

From: Alan Stern <[email protected]>

commit c9a4cb204e9eb7fa7dfbe3f7d3a674fa530aa193 upstream.

usb_find_alt_setting() takes a pointer to a struct usb_host_config as an argument; it searches for an interface with specified interface and alternate setting numbers in that config. However, it crashes if the usb_host_config pointer argument is NULL.

Since this is a general-purpose routine, available for use in many places, we want to to be more robust. This patch makes it return NULL whenever the config argument is NULL.

Signed-off-by Alan Stern <[email protected]>

Reported-by [email protected]

CC <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/usb.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/usb/core/usb.c +2 -0

@@ -79,6 +79,8 @@ struct usb_host_interface *usb_find_alt_
 	struct usb_interface_cache *intf_cache = NULL;
 	int i;
 
+	if (!config)
+		return NULL;
 	for (i = 0; i < config->desc.bNumInterfaces; i++) {
 		if (config->intf_cache[i]->altsetting[0].desc.bInterfaceNumber
 				== iface_num) {

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #55 lore raw

PATCH 55/120 slub: make ->cpu_partial unsigned int

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

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

From: Alexey Dobriyan <[email protected]>

commit e5d9998f3e09359b372a037a6ac55ba235d95d57 upstream.

	/*
	 * cpu_partial determined the maximum number of objects
	 * kept in the per cpu partial lists of a processor.
	 */

Can't be negative.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Alexey Dobriyan <[email protected]>

Acked-by Christoph Lameter <[email protected]>

Cc Pekka Enberg <[email protected]>

Cc David Rientjes <[email protected]>

Cc Joonsoo Kim <[email protected]>

Signed-off-by zhong jiang <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/linux/slub_def.h |    3 ++-
 mm/slub.c                |    6 +++---
 2 files changed, 5 insertions(+), 4 deletions(-)

include/linux/slub_def.h +2 -1

@@ -67,7 +67,8 @@ struct kmem_cache {
 	int size;		/* The size of an object including meta data */
 	int object_size;	/* The size of an object without meta data */
 	int offset;		/* Free pointer offset. */
-	int cpu_partial;	/* Number of per cpu partial objects to keep around */
+	/* Number of per cpu partial objects to keep around */
+	unsigned int cpu_partial;
 	struct kmem_cache_order_objects oo;
 
 	/* Allocation and freeing of slabs */

mm/slub.c +3 -3

@@ -1577,7 +1577,7 @@ static void *get_partial_node(struct kme
 {
 	struct page *page, *page2;
 	void *object = NULL;
-	int available = 0;
+	unsigned int available = 0;
 	int objects;
 
 	/*

@@ -4366,10 +4366,10 @@ static ssize_t cpu_partial_show(struct k
 static ssize_t cpu_partial_store(struct kmem_cache *s, const char *buf,
 				 size_t length)
 {
-	unsigned long objects;
+	unsigned int objects;
 	int err;
 
-	err = kstrtoul(buf, 10, &objects);
+	err = kstrtouint(buf, 10, &objects);
 	if (err)
 		return err;
 	if (objects && !kmem_cache_has_cpu_partial(s))

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #56 lore raw

PATCH 56/120 media: uvcvideo: Support realteks UVC 1.5 device

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

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

From: ming_qian <[email protected]>

commit f620d1d7afc7db57ab59f35000752840c91f67e7 upstream.

media: uvcvideo: Support UVC 1.5 video probe & commit controls

The length of UVC 1.5 video control is 48, and it is 34 for UVC 1.1. Change it to 48 for UVC 1.5 device, and the UVC 1.5 device can be recognized.

More changes to the driver are needed for full UVC 1.5 compatibility. However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have been reported to work well.

[[email protected]: Factor out code to helper function, update size checks]

Signed-off-by ming_qian <[email protected]>

Signed-off-by Laurent Pinchart <[email protected]>

Tested-by Kai-Heng Feng <[email protected]>

Tested-by Ana Guerrero Lopez <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/usb/uvc/uvc_video.c |   24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

drivers/media/usb/uvc/uvc_video.c +18 -6

@@ -155,14 +155,27 @@ static void uvc_fixup_video_ctrl(struct
 	}
 }
 
+static size_t uvc_video_ctrl_size(struct uvc_streaming *stream)
+{
+	/*
+	 * Return the size of the video probe and commit controls, which depends
+	 * on the protocol version.
+	 */
+	if (stream->dev->uvc_version < 0x0110)
+		return 26;
+	else if (stream->dev->uvc_version < 0x0150)
+		return 34;
+	else
+		return 48;
+}
+
 static int uvc_get_video_ctrl(struct uvc_streaming *stream,
 	struct uvc_streaming_control *ctrl, int probe, __u8 query)
 {
+	__u16 size = uvc_video_ctrl_size(stream);
 	__u8 *data;
-	__u16 size;
 	int ret;
 
-	size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
 	if ((stream->dev->quirks & UVC_QUIRK_PROBE_DEF) &&
 			query == UVC_GET_DEF)
 		return -EIO;

@@ -217,7 +230,7 @@ static int uvc_get_video_ctrl(struct uvc
 	ctrl->dwMaxVideoFrameSize = get_unaligned_le32(&data[18]);
 	ctrl->dwMaxPayloadTransferSize = get_unaligned_le32(&data[22]);
 
-	if (size == 34) {
+	if (size >= 34) {
 		ctrl->dwClockFrequency = get_unaligned_le32(&data[26]);
 		ctrl->bmFramingInfo = data[30];
 		ctrl->bPreferedVersion = data[31];

@@ -246,11 +259,10 @@ out:
 static int uvc_set_video_ctrl(struct uvc_streaming *stream,
 	struct uvc_streaming_control *ctrl, int probe)
 {
+	__u16 size = uvc_video_ctrl_size(stream);
 	__u8 *data;
-	__u16 size;
 	int ret;
 
-	size = stream->dev->uvc_version >= 0x0110 ? 34 : 26;
 	data = kzalloc(size, GFP_KERNEL);
 	if (data == NULL)
 		return -ENOMEM;

@@ -267,7 +279,7 @@ static int uvc_set_video_ctrl(struct uvc
 	put_unaligned_le32(ctrl->dwMaxVideoFrameSize, &data[18]);
 	put_unaligned_le32(ctrl->dwMaxPayloadTransferSize, &data[22]);
 
-	if (size == 34) {
+	if (size >= 34) {
 		put_unaligned_le32(ctrl->dwClockFrequency, &data[26]);
 		data[30] = ctrl->bmFramingInfo;
 		data[31] = ctrl->bPreferedVersion;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #57 lore raw

PATCH 57/120 USB: usbdevfs: sanitize flags more

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

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

From: Oliver Neukum <[email protected]>

commit 7a68d9fb851012829c29e770621905529bd9490b upstream.

Requesting a ZERO_PACKET or not is sensible only for output. In the input direction the device decides. Likewise accepting short packets makes sense only for input.

This allows operation with panic_on_warn without opening up a local DOS.

Signed-off-by Oliver Neukum <[email protected]>

Reported-by [email protected]

Fixes 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow")

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/devio.c |   19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

drivers/usb/core/devio.c +16 -3

@@ -1286,10 +1286,13 @@ static int proc_do_submiturb(struct usb_
 	struct async *as = NULL;
 	struct usb_ctrlrequest *dr = NULL;
 	unsigned int u, totlen, isofrmlen;
-	int i, ret, is_in, num_sgs = 0, ifnum = -1;
+	int i, ret, num_sgs = 0, ifnum = -1;
 	int number_of_packets = 0;
 	unsigned int stream_id = 0;
 	void *buf;
+	bool is_in;
+	bool allow_short = false;
+	bool allow_zero = false;
 	unsigned long mask =	USBDEVFS_URB_SHORT_NOT_OK |
 				USBDEVFS_URB_BULK_CONTINUATION |
 				USBDEVFS_URB_NO_FSBR |

@@ -1323,6 +1326,8 @@ static int proc_do_submiturb(struct usb_
 	u = 0;
 	switch(uurb->type) {
 	case USBDEVFS_URB_TYPE_CONTROL:
+		if (is_in)
+			allow_short = true;
 		if (!usb_endpoint_xfer_control(&ep->desc))
 			return -EINVAL;
 		/* min 8 byte setup packet */

@@ -1363,6 +1368,10 @@ static int proc_do_submiturb(struct usb_
 		break;
 
 	case USBDEVFS_URB_TYPE_BULK:
+		if (!is_in)
+			allow_zero = true;
+		else
+			allow_short = true;
 		switch (usb_endpoint_type(&ep->desc)) {
 		case USB_ENDPOINT_XFER_CONTROL:
 		case USB_ENDPOINT_XFER_ISOC:

@@ -1383,6 +1392,10 @@ static int proc_do_submiturb(struct usb_
 		if (!usb_endpoint_xfer_int(&ep->desc))
 			return -EINVAL;
  interrupt_urb:
+		if (!is_in)
+			allow_zero = true;
+		else
+			allow_short = true;
 		break;
 
 	case USBDEVFS_URB_TYPE_ISO:

@@ -1508,11 +1521,11 @@ static int proc_do_submiturb(struct usb_
 	u = (is_in ? URB_DIR_IN : URB_DIR_OUT);
 	if (uurb->flags & USBDEVFS_URB_ISO_ASAP)
 		u |= URB_ISO_ASAP;
-	if (uurb->flags & USBDEVFS_URB_SHORT_NOT_OK && is_in)
+	if (allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)
 		u |= URB_SHORT_NOT_OK;
 	if (uurb->flags & USBDEVFS_URB_NO_FSBR)
 		u |= URB_NO_FSBR;
-	if (uurb->flags & USBDEVFS_URB_ZERO_PACKET)
+	if (allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET)
 		u |= URB_ZERO_PACKET;
 	if (uurb->flags & USBDEVFS_URB_NO_INTERRUPT)
 		u |= URB_NO_INTERRUPT;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #58 lore raw

PATCH 58/120 USB: usbdevfs: restore warning for nonsensical flags

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

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

From: Oliver Neukum <[email protected]>

commit 81e0403b26d94360abd1f6a57311337973bc82cd upstream.

If we filter flags before they reach the core we need to generate our own warnings.

Signed-off-by Oliver Neukum <[email protected]>

Fixes 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow")

Cc stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/devio.c |    5 +++++
 1 file changed, 5 insertions(+)

drivers/usb/core/devio.c +5 -0

@@ -1531,6 +1531,11 @@ static int proc_do_submiturb(struct usb_
 		u |= URB_NO_INTERRUPT;
 	as->urb->transfer_flags = u;
 
+	if (!allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)
+		dev_warn(&ps->dev->dev, "Requested nonsensical USBDEVFS_URB_SHORT_NOT_OK.\n");
+	if (!allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET)
+		dev_warn(&ps->dev->dev, "Requested nonsensical USBDEVFS_URB_ZERO_PACKET.\n");
+
 	as->urb->transfer_buffer_length = uurb->buffer_length;
 	as->urb->setup_packet = (unsigned char *)dr;
 	dr = NULL;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #59 lore raw

PATCH 59/120 Revert "usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()"

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

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

From: Sebastian Andrzej Siewior <[email protected]>

commit e871db8d78df1c411032cbb3acfdf8930509360e upstream.

This reverts commit 6e22e3af7bb3a7b9dc53cb4687659f6e63fca427.

The bug the patch describes to, has been already fixed in commit 2df6948428542 ("USB: cdc-wdm: don't enable interrupts in USB-giveback") so need to this, revert it.

Fixes 6e22e3af7bb3 ("usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()")

Cc stable <[email protected]>

Signed-off-by Sebastian Andrzej Siewior <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/class/cdc-wdm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/usb/class/cdc-wdm.c +1 -1

@@ -452,7 +452,7 @@ static int clear_wdm_read_flag(struct wd
 
 	set_bit(WDM_RESPONDING, &desc->flags);
 	spin_unlock_irq(&desc->iuspin);
-	rv = usb_submit_urb(desc->response, GFP_ATOMIC);
+	rv = usb_submit_urb(desc->response, GFP_KERNEL);
 	spin_lock_irq(&desc->iuspin);
 	if (rv) {
 		dev_err(&desc->intf->dev,

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #60 lore raw

PATCH 60/120 USB: remove LPM management from usb_driver_claim_interface()

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

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

From: Alan Stern <[email protected]>

commit c183813fcee44a249339b7c46e1ad271ca1870aa upstream.

usb_driver_claim_interface() disables and re-enables Link Power Management, but it shouldn't do either one, for the reasons listed below. This patch removes the two LPM-related function calls from the routine.

The reason for disabling LPM in the analogous function usb_probe_interface() is so that drivers won't have to deal with unwanted LPM transitions in their probe routine. But usb_driver_claim_interface() doesn't call the driver's probe routine (or any other callbacks), so that reason doesn't apply here.

Furthermore, no driver other than usbfs will ever call usb_driver_claim_interface() unless it is already bound to another interface in the same device, which means disabling LPM here would be redundant. usbfs doesn't interact with LPM at all.

Lastly, the error return from usb_unlocked_disable_lpm() isn't handled properly; the code doesn't clean up its earlier actions before returning.

Signed-off-by Alan Stern <[email protected]>

Fixes 8306095fd2c1 ("USB: Disable USB 3.0 LPM in critical sections.")

CC <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/core/driver.c |   15 ---------------
 1 file changed, 15 deletions(-)

drivers/usb/core/driver.c +0 ~~-15~~

@@ -506,7 +506,6 @@ int usb_driver_claim_interface(struct us
 	struct device *dev;
 	struct usb_device *udev;
 	int retval = 0;
-	int lpm_disable_error = -ENODEV;
 
 	if (!iface)
 		return -ENODEV;

@@ -523,16 +522,6 @@ int usb_driver_claim_interface(struct us
 
 	iface->condition = USB_INTERFACE_BOUND;
 
-	/* See the comment about disabling LPM in usb_probe_interface(). */
-	if (driver->disable_hub_initiated_lpm) {
-		lpm_disable_error = usb_unlocked_disable_lpm(udev);
-		if (lpm_disable_error) {
-			dev_err(&iface->dev, "%s Failed to disable LPM for driver %s\n.",
-					__func__, driver->name);
-			return -ENOMEM;
-		}
-	}
-
 	/* Claimed interfaces are initially inactive (suspended) and
 	 * runtime-PM-enabled, but only if the driver has autosuspend
 	 * support.  Otherwise they are marked active, to prevent the

@@ -551,10 +540,6 @@ int usb_driver_claim_interface(struct us
 	if (device_is_registered(dev))
 		retval = device_bind_driver(dev);
 
-	/* Attempt to re-enable USB3 LPM, if the disable was successful. */
-	if (!lpm_disable_error)
-		usb_unlocked_enable_lpm(udev);
-
 	if (retval) {
 		dev->driver = NULL;
 		usb_set_intfdata(iface, NULL);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #61 lore raw

PATCH 61/120 scsi: target: iscsi: Use bin2hex instead of a re-implementation

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

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

From: Vincent Pelletier <[email protected]>

commit 8c39e2699f8acb2e29782a834e56306da24937fe upstream.

Signed-off-by Vincent Pelletier <[email protected]>

Reviewed-by Mike Christie <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

[[email protected]: hunk context change for 4.4 and 4.9, no code change]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/target/iscsi/iscsi_target_auth.c |   15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

drivers/target/iscsi/iscsi_target_auth.c +3 ~~-12~~

@@ -26,15 +26,6 @@
 #include "iscsi_target_nego.h"
 #include "iscsi_target_auth.h"
 
-static void chap_binaryhex_to_asciihex(char *dst, char *src, int src_len)
-{
-	int i;
-
-	for (i = 0; i < src_len; i++) {
-		sprintf(&dst[i*2], "%02x", (int) src[i] & 0xff);
-	}
-}
-
 static void chap_gen_challenge(
 	struct iscsi_conn *conn,
 	int caller,

@@ -47,7 +38,7 @@ static void chap_gen_challenge(
 	memset(challenge_asciihex, 0, CHAP_CHALLENGE_LENGTH * 2 + 1);
 
 	get_random_bytes(chap->challenge, CHAP_CHALLENGE_LENGTH);
-	chap_binaryhex_to_asciihex(challenge_asciihex, chap->challenge,
+	bin2hex(challenge_asciihex, chap->challenge,
 				CHAP_CHALLENGE_LENGTH);
 	/*
 	 * Set CHAP_C, and copy the generated challenge into c_str.

@@ -287,7 +278,7 @@ static int chap_server_compute_md5(
 	}
 	crypto_free_hash(tfm);
 
-	chap_binaryhex_to_asciihex(response, server_digest, MD5_SIGNATURE_SIZE);
+	bin2hex(response, server_digest, MD5_SIGNATURE_SIZE);
 	pr_debug("[server] MD5 Server Digest: %s\n", response);
 
 	if (memcmp(server_digest, client_digest, MD5_SIGNATURE_SIZE) != 0) {

@@ -431,7 +422,7 @@ static int chap_server_compute_md5(
 	/*
 	 * Convert response from binary hex to ascii hext.
 	 */
-	chap_binaryhex_to_asciihex(response, digest, MD5_SIGNATURE_SIZE);
+	bin2hex(response, digest, MD5_SIGNATURE_SIZE);
 	*nr_out_len += sprintf(nr_out_ptr + *nr_out_len, "CHAP_R=0x%s",
 			response);
 	*nr_out_len += 1;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #62 lore raw

PATCH 62/120 staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free

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

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

From: Greg Hackmann <[email protected]>

commit 2c155709e4ef2d86d0176aac82e44c048a7e0255 upstream.

The ION_IOC_{MAP,SHARE} ioctls drop and reacquire client->lock several times while operating on one of the client's ion_handles. This creates windows where userspace can call ION_IOC_FREE on the same client with the same handle, and effectively make the kernel drop its own reference. For example:

- thread A: ION_IOC_ALLOC creates an ion_handle with refcount 1
- thread A: starts ION_IOC_MAP and increments the refcount to 2
- thread B: ION_IOC_FREE decrements the refcount to 1
- thread B: ION_IOC_FREE decrements the refcount to 0 and frees the handle
- thread A: continues ION_IOC_MAP with a dangling ion_handle * to freed memory

Fix this by holding client->lock for the duration of ION_IOC_{MAP,SHARE}, preventing the concurrent ION_IOC_FREE. Also remove ion_handle_get_by_id(), since there's literally no way to use it safely.

This patch is applied on top of 4.4.y, and applies to older kernels too. 4.9.y was fixed separately. Kernels 4.12 and later are unaffected, since all the underlying ion_handle infrastructure has been ripped out.

Cc [email protected] # v4.4-

Acked-by Laura Abbott <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/staging/android/ion/ion.c |   60 +++++++++++++++++++++++---------------
 1 file changed, 37 insertions(+), 23 deletions(-)

drivers/staging/android/ion/ion.c +37 ~~-23~~

@@ -451,18 +451,6 @@ static struct ion_handle *ion_handle_get
 	return ERR_PTR(-EINVAL);
 }
 
-struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
-						int id)
-{
-	struct ion_handle *handle;
-
-	mutex_lock(&client->lock);
-	handle = ion_handle_get_by_id_nolock(client, id);
-	mutex_unlock(&client->lock);
-
-	return handle;
-}
-
 static bool ion_handle_validate(struct ion_client *client,
 				struct ion_handle *handle)
 {

@@ -1138,23 +1126,27 @@ static struct dma_buf_ops dma_buf_ops =
 	.kunmap = ion_dma_buf_kunmap,
 };
 
-struct dma_buf *ion_share_dma_buf(struct ion_client *client,
-						struct ion_handle *handle)
+static struct dma_buf *__ion_share_dma_buf(struct ion_client *client,
+					   struct ion_handle *handle,
+					   bool lock_client)
 {
 	struct ion_buffer *buffer;
 	struct dma_buf *dmabuf;
 	bool valid_handle;
 
-	mutex_lock(&client->lock);
+	if (lock_client)
+		mutex_lock(&client->lock);
 	valid_handle = ion_handle_validate(client, handle);
 	if (!valid_handle) {
 		WARN(1, "%s: invalid handle passed to share.\n", __func__);
-		mutex_unlock(&client->lock);
+		if (lock_client)
+			mutex_unlock(&client->lock);
 		return ERR_PTR(-EINVAL);
 	}
 	buffer = handle->buffer;
 	ion_buffer_get(buffer);
-	mutex_unlock(&client->lock);
+	if (lock_client)
+		mutex_unlock(&client->lock);
 
 	dmabuf = dma_buf_export(buffer, &dma_buf_ops, buffer->size, O_RDWR,
 				NULL);

@@ -1165,14 +1157,21 @@ struct dma_buf *ion_share_dma_buf(struct
 
 	return dmabuf;
 }
+
+struct dma_buf *ion_share_dma_buf(struct ion_client *client,
+				  struct ion_handle *handle)
+{
+	return __ion_share_dma_buf(client, handle, true);
+}
 EXPORT_SYMBOL(ion_share_dma_buf);
 
-int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle)
+static int __ion_share_dma_buf_fd(struct ion_client *client,
+				  struct ion_handle *handle, bool lock_client)
 {
 	struct dma_buf *dmabuf;
 	int fd;
 
-	dmabuf = ion_share_dma_buf(client, handle);
+	dmabuf = __ion_share_dma_buf(client, handle, lock_client);
 	if (IS_ERR(dmabuf))
 		return PTR_ERR(dmabuf);

@@ -1182,8 +1181,19 @@ int ion_share_dma_buf_fd(struct ion_clie
 
 	return fd;
 }
+
+int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle)
+{
+	return __ion_share_dma_buf_fd(client, handle, true);
+}
 EXPORT_SYMBOL(ion_share_dma_buf_fd);
 
+static int ion_share_dma_buf_fd_nolock(struct ion_client *client,
+				       struct ion_handle *handle)
+{
+	return __ion_share_dma_buf_fd(client, handle, false);
+}
+
 struct ion_handle *ion_import_dma_buf(struct ion_client *client, int fd)
 {
 	struct dma_buf *dmabuf;

@@ -1330,11 +1340,15 @@ static long ion_ioctl(struct file *filp,
 	{
 		struct ion_handle *handle;
 
-		handle = ion_handle_get_by_id(client, data.handle.handle);
-		if (IS_ERR(handle))
+		mutex_lock(&client->lock);
+		handle = ion_handle_get_by_id_nolock(client, data.handle.handle);
+		if (IS_ERR(handle)) {
+			mutex_unlock(&client->lock);
 			return PTR_ERR(handle);
-		data.fd.fd = ion_share_dma_buf_fd(client, handle);
-		ion_handle_put(handle);
+		}
+		data.fd.fd = ion_share_dma_buf_fd_nolock(client, handle);
+		ion_handle_put_nolock(handle);
+		mutex_unlock(&client->lock);
 		if (data.fd.fd < 0)
 			ret = data.fd.fd;
 		break;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #63 lore raw

PATCH 63/120 arm64: KVM: Tighten guest core register access from userspace

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

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

From: Dave Martin <[email protected]>

commit d26c25a9d19b5976b319af528886f89cf455692d upstream.

We currently allow userspace to access the core register file in about any possible way, including straddling multiple registers and doing unaligned accesses.

This is not the expected use of the ABI, and nobody is actually using it that way. Let's tighten it by explicitly checking the size and alignment for each field of the register file.

Fixes 2f4a07c5f9fe ("arm64: KVM: guest one-reg interface")

Reviewed-by Christoffer Dall <[email protected]>

Reviewed-by Mark Rutland <[email protected]>

Signed-off-by Dave Martin <[email protected]>

[maz: rewrote Dave's initial patch to be more easily backported]

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/kvm/guest.c |   45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

arch/arm64/kvm/guest.c +45 -0

@@ -46,6 +46,45 @@ static u64 core_reg_offset_from_id(u64 i
 	return id & ~(KVM_REG_ARCH_MASK | KVM_REG_SIZE_MASK | KVM_REG_ARM_CORE);
 }
 
+static int validate_core_offset(const struct kvm_one_reg *reg)
+{
+	u64 off = core_reg_offset_from_id(reg->id);
+	int size;
+
+	switch (off) {
+	case KVM_REG_ARM_CORE_REG(regs.regs[0]) ...
+	     KVM_REG_ARM_CORE_REG(regs.regs[30]):
+	case KVM_REG_ARM_CORE_REG(regs.sp):
+	case KVM_REG_ARM_CORE_REG(regs.pc):
+	case KVM_REG_ARM_CORE_REG(regs.pstate):
+	case KVM_REG_ARM_CORE_REG(sp_el1):
+	case KVM_REG_ARM_CORE_REG(elr_el1):
+	case KVM_REG_ARM_CORE_REG(spsr[0]) ...
+	     KVM_REG_ARM_CORE_REG(spsr[KVM_NR_SPSR - 1]):
+		size = sizeof(__u64);
+		break;
+
+	case KVM_REG_ARM_CORE_REG(fp_regs.vregs[0]) ...
+	     KVM_REG_ARM_CORE_REG(fp_regs.vregs[31]):
+		size = sizeof(__uint128_t);
+		break;
+
+	case KVM_REG_ARM_CORE_REG(fp_regs.fpsr):
+	case KVM_REG_ARM_CORE_REG(fp_regs.fpcr):
+		size = sizeof(__u32);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	if (KVM_REG_SIZE(reg->id) == size &&
+	    IS_ALIGNED(off, size / sizeof(__u32)))
+		return 0;
+
+	return -EINVAL;
+}
+
 static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 {
 	/*

@@ -65,6 +104,9 @@ static int get_core_reg(struct kvm_vcpu
 	    (off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
 		return -ENOENT;
 
+	if (validate_core_offset(reg))
+		return -EINVAL;
+
 	if (copy_to_user(uaddr, ((u32 *)regs) + off, KVM_REG_SIZE(reg->id)))
 		return -EFAULT;

@@ -87,6 +129,9 @@ static int set_core_reg(struct kvm_vcpu
 	    (off + (KVM_REG_SIZE(reg->id) / sizeof(__u32))) >= nr_regs)
 		return -ENOENT;
 
+	if (validate_core_offset(reg))
+		return -EINVAL;
+
 	if (KVM_REG_SIZE(reg->id) > sizeof(tmp))
 		return -EINVAL;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:34 UTC #64 lore raw

PATCH 64/120 ext4: verify the depth of extent tree in ext4_find_extent()

https://bugzilla.kernel.org/show_bug.cgi?id=199417

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

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

From: Theodore Ts'o <[email protected]>

commit bc890a60247171294acc0bd67d211fa4b88d40ba upstream.

If there is a corupted file system where the claimed depth of the extent tree is -1, this can cause a massive buffer overrun leading to sadness.

This addresses CVE-2018-10877.

[bwh: Backported to 3.16: return -EIO instead of -EFSCORRUPTED]

Cc Greg Hackmann <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/ext4_extents.h |    1 +
 fs/ext4/extents.c      |    6 ++++++
 2 files changed, 7 insertions(+)

fs/ext4/ext4_extents.h +1 -0

@@ -103,6 +103,7 @@ struct ext4_extent_header {
 };
 
 #define EXT4_EXT_MAGIC		cpu_to_le16(0xf30a)
+#define EXT4_MAX_EXTENT_DEPTH 5
 
 #define EXT4_EXTENT_TAIL_OFFSET(hdr) \
 	(sizeof(struct ext4_extent_header) + \

fs/ext4/extents.c +6 -0

@@ -870,6 +870,12 @@ ext4_find_extent(struct inode *inode, ex
 
 	eh = ext_inode_hdr(inode);
 	depth = ext_depth(inode);
+	if (depth < 0 || depth > EXT4_MAX_EXTENT_DEPTH) {
+		EXT4_ERROR_INODE(inode, "inode has invalid extent depth: %d",
+				 depth);
+		ret = -EIO;
+		goto err;
+	}
 
 	if (path) {
 		ext4_ext_drop_refs(path);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #65 lore raw

PATCH 65/120 thermal: of-thermal: disable passive polling when thermal zone is disabled

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

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

From: Anson Huang <[email protected]>

[ Upstream commit 152395fd03d4ce1e535a75cdbf58105e50587611 ]

When thermal zone is in passive mode, disabling its mode from sysfs is NOT taking effect at all, it is still polling the temperature of the disabled thermal zone and handling all thermal trips, it makes user confused. The disabling operation should disable the thermal zone behavior completely, for both active and passive mode, this patch clears the passive_delay when thermal zone is disabled and restores it when it is enabled.

Signed-off-by Anson Huang <[email protected]>

Signed-off-by Eduardo Valentin <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/thermal/of-thermal.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

drivers/thermal/of-thermal.c +5 -2

@@ -209,10 +209,13 @@ static int of_thermal_set_mode(struct th
 
 	mutex_lock(&tz->lock);
 
-	if (mode == THERMAL_DEVICE_ENABLED)
+	if (mode == THERMAL_DEVICE_ENABLED) {
 		tz->polling_delay = data->polling_delay;
-	else
+		tz->passive_delay = data->passive_delay;
+	} else {
 		tz->polling_delay = 0;
+		tz->passive_delay = 0;
+	}
 
 	mutex_unlock(&tz->lock);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #66 lore raw

PATCH 66/120 e1000: check on netif_running() before calling e1000_up()

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

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

From: Bo Chen <[email protected]>

[ Upstream commit cf1acec008f8d7761aa3fd7c4bca7e17b2d2512d ]

When the device is not up, the call to 'e1000_up()' from the error handling path of 'e1000_set_ringparam()' causes a kernel oops with a null-pointer dereference. The null-pointer dereference is triggered in function 'e1000_alloc_rx_buffers()' at line 'buffer_info = &rx_ring->buffer_info[i]'.

This bug was reported by COD, a tool for testing kernel module binaries I am building. This bug was also detected by KFI from Dr. Kai Cong.

This patch fixes the bug by checking on 'netif_running()' before calling 'e1000_up()' in 'e1000_set_ringparam()'.

Signed-off-by Bo Chen <[email protected]>

Acked-by Alexander Duyck <[email protected]>

Tested-by Aaron Brown <[email protected]>

Signed-off-by Jeff Kirsher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/e1000/e1000_ethtool.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/net/ethernet/intel/e1000/e1000_ethtool.c +2 -1

@@ -666,7 +666,8 @@ err_setup_rx:
 err_alloc_rx:
 	kfree(txdr);
 err_alloc_tx:
-	e1000_up(adapter);
+	if (netif_running(adapter->netdev))
+		e1000_up(adapter);
 err_setup:
 	clear_bit(__E1000_RESETTING, &adapter->flags);
 	return err;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #67 lore raw

PATCH 67/120 e1000: ensure to free old tx/rx rings in set_ringparam()

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

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

From: Bo Chen <[email protected]>

[ Upstream commit ee400a3f1bfe7004a3e14b81c38ccc5583c26295 ]

In 'e1000_set_ringparam()', the tx_ring and rx_ring are updated with new value and the old tx/rx rings are freed only when the device is up. There are resource leaks on old tx/rx rings when the device is not up. This bug is reported by COD, a tool for testing kernel module binaries I am building.

This patch fixes the bug by always calling 'kfree()' on old tx/rx rings in 'e1000_set_ringparam()'.

Signed-off-by Bo Chen <[email protected]>

Reviewed-by Alexander Duyck <[email protected]>

Tested-by Aaron Brown <[email protected]>

Signed-off-by Jeff Kirsher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/intel/e1000/e1000_ethtool.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/e1000/e1000_ethtool.c +2 -2

@@ -646,14 +646,14 @@ static int e1000_set_ringparam(struct ne
 		adapter->tx_ring = tx_old;
 		e1000_free_all_rx_resources(adapter);
 		e1000_free_all_tx_resources(adapter);
-		kfree(tx_old);
-		kfree(rx_old);
 		adapter->rx_ring = rxdr;
 		adapter->tx_ring = txdr;
 		err = e1000_up(adapter);
 		if (err)
 			goto err_setup;
 	}
+	kfree(tx_old);
+	kfree(rx_old);
 
 	clear_bit(__E1000_RESETTING, &adapter->flags);
 	return 0;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #68 lore raw

PATCH 68/120 hwmon: (adt7475) Make adt7475_read_word() return errors

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit f196dec6d50abb2e65fb54a0621b2f1b4d922995 ]

The adt7475_read_word() function was meant to return negative error codes on failure.

Signed-off-by Dan Carpenter <[email protected]>

Reviewed-by Tokunori Ikegami <[email protected]>

Signed-off-by Guenter Roeck <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/hwmon/adt7475.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

drivers/hwmon/adt7475.c +9 -5

@@ -274,14 +274,18 @@ static inline u16 volt2reg(int channel,
 	return clamp_val(reg, 0, 1023) & (0xff << 2);
 }
 
-static u16 adt7475_read_word(struct i2c_client *client, int reg)
+static int adt7475_read_word(struct i2c_client *client, int reg)
 {
-	u16 val;
+	int val1, val2;
 
-	val = i2c_smbus_read_byte_data(client, reg);
-	val |= (i2c_smbus_read_byte_data(client, reg + 1) << 8);
+	val1 = i2c_smbus_read_byte_data(client, reg);
+	if (val1 < 0)
+		return val1;
+	val2 = i2c_smbus_read_byte_data(client, reg + 1);
+	if (val2 < 0)
+		return val2;
 
-	return val;
+	return val1 | (val2 << 8);
 }
 
 static void adt7475_write_word(struct i2c_client *client, int reg, u16 val)

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #69 lore raw

PATCH 69/120 arm64: KVM: Sanitize PSTATE.M when being set from userspace

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

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

From: Marc Zyngier <[email protected]>

commit 2a3f93459d689d990b3ecfbe782fec89b97d3279 upstream.

Not all execution modes are valid for a guest, and some of them depend on what the HW actually supports. Let's verify that what userspace provides is compatible with both the VM settings and the HW capabilities.

Fixes 0d854a60b1d7 ("arm64: KVM: enable initialization of a 32bit vcpu")

Reviewed-by Christoffer Dall <[email protected]>

Reviewed-by Mark Rutland <[email protected]>

Reviewed-by Dave Martin <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/arm64/include/asm/kvm_emulate.h |    5 +++++
 arch/arm64/kvm/guest.c               |   10 +++++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

arch/arm64/include/asm/kvm_emulate.h +5 -0

@@ -38,6 +38,11 @@ void kvm_inject_undefined(struct kvm_vcp
 void kvm_inject_dabt(struct kvm_vcpu *vcpu, unsigned long addr);
 void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
 
+static inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
+{
+	return !(vcpu->arch.hcr_el2 & HCR_RW);
+}
+
 static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
 {
 	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;

arch/arm64/kvm/guest.c +9 -1

@@ -141,17 +141,25 @@ static int set_core_reg(struct kvm_vcpu
 	}
 
 	if (off == KVM_REG_ARM_CORE_REG(regs.pstate)) {
-		u32 mode = (*(u32 *)valp) & COMPAT_PSR_MODE_MASK;
+		u64 mode = (*(u64 *)valp) & COMPAT_PSR_MODE_MASK;
 		switch (mode) {
 		case COMPAT_PSR_MODE_USR:
+			if ((read_cpuid(ID_AA64PFR0_EL1) & 0xf) != 2)
+				return -EINVAL;
+			break;
 		case COMPAT_PSR_MODE_FIQ:
 		case COMPAT_PSR_MODE_IRQ:
 		case COMPAT_PSR_MODE_SVC:
 		case COMPAT_PSR_MODE_ABT:
 		case COMPAT_PSR_MODE_UND:
+			if (!vcpu_el1_is_32bit(vcpu))
+				return -EINVAL;
+			break;
 		case PSR_MODE_EL0t:
 		case PSR_MODE_EL1t:
 		case PSR_MODE_EL1h:
+			if (vcpu_el1_is_32bit(vcpu))
+				return -EINVAL;
 			break;
 		default:
 			err = -EINVAL;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #70 lore raw

PATCH 70/120 media: v4l: event: Prevent freeing event subscriptions while accessed

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

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

From: Sakari Ailus <[email protected]>

commit ad608fbcf166fec809e402d548761768f602702c upstream.

The event subscriptions are added to the subscribed event list while holding a spinlock, but that lock is subsequently released while still accessing the subscription object. This makes it possible to unsubscribe the event --- and freeing the subscription object's memory --- while the subscription object is simultaneously accessed.

Prevent this by adding a mutex to serialise the event subscription and unsubscription. This also gives a guarantee to the callback ops that the add op has returned before the del op is called.

This change also results in making the elems field less special:
subscriptions are only added to the event list once they are fully initialised.

Signed-off-by Sakari Ailus <[email protected]>

Reviewed-by Hans Verkuil <[email protected]>

Reviewed-by Laurent Pinchart <[email protected]>

Cc [email protected] # for 4.14 and up

Fixes c3b5b0241f62 ("V4L/DVB: V4L: Events: Add backend")

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/media/v4l2-core/v4l2-event.c |   37 +++++++++++++++++------------------
 drivers/media/v4l2-core/v4l2-fh.c    |    2 +
 include/media/v4l2-fh.h              |    1 
 3 files changed, 22 insertions(+), 18 deletions(-)

drivers/media/v4l2-core/v4l2-event.c +19 ~~-18~~

@@ -119,14 +119,6 @@ static void __v4l2_event_queue_fh(struct
 	if (sev == NULL)
 		return;
 
-	/*
-	 * If the event has been added to the fh->subscribed list, but its
-	 * add op has not completed yet elems will be 0, treat this as
-	 * not being subscribed.
-	 */
-	if (!sev->elems)
-		return;
-
 	/* Increase event sequence number on fh. */
 	fh->sequence++;

@@ -209,6 +201,7 @@ int v4l2_event_subscribe(struct v4l2_fh
 	struct v4l2_subscribed_event *sev, *found_ev;
 	unsigned long flags;
 	unsigned i;
+	int ret = 0;
 
 	if (sub->type == V4L2_EVENT_ALL)
 		return -EINVAL;

@@ -226,31 +219,36 @@ int v4l2_event_subscribe(struct v4l2_fh
 	sev->flags = sub->flags;
 	sev->fh = fh;
 	sev->ops = ops;
+	sev->elems = elems;
+
+	mutex_lock(&fh->subscribe_lock);
 
 	spin_lock_irqsave(&fh->vdev->fh_lock, flags);
 	found_ev = v4l2_event_subscribed(fh, sub->type, sub->id);
-	if (!found_ev)
-		list_add(&sev->list, &fh->subscribed);
 	spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
 
 	if (found_ev) {
+		/* Already listening */
 		kfree(sev);
-		return 0; /* Already listening */
+		goto out_unlock;
 	}
 
 	if (sev->ops && sev->ops->add) {
-		int ret = sev->ops->add(sev, elems);
+		ret = sev->ops->add(sev, elems);
 		if (ret) {
-			sev->ops = NULL;
-			v4l2_event_unsubscribe(fh, sub);
-			return ret;
+			kfree(sev);
+			goto out_unlock;
 		}
 	}
 
-	/* Mark as ready for use */
-	sev->elems = elems;
+	spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+	list_add(&sev->list, &fh->subscribed);
+	spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
 
-	return 0;
+out_unlock:
+	mutex_unlock(&fh->subscribe_lock);
+
+	return ret;
 }
 EXPORT_SYMBOL_GPL(v4l2_event_subscribe);

@@ -289,6 +287,8 @@ int v4l2_event_unsubscribe(struct v4l2_f
 		return 0;
 	}
 
+	mutex_lock(&fh->subscribe_lock);
+
 	spin_lock_irqsave(&fh->vdev->fh_lock, flags);
 
 	sev = v4l2_event_subscribed(fh, sub->type, sub->id);

@@ -307,6 +307,7 @@ int v4l2_event_unsubscribe(struct v4l2_f
 		sev->ops->del(sev);
 
 	kfree(sev);
+	mutex_unlock(&fh->subscribe_lock);
 
 	return 0;
 }

drivers/media/v4l2-core/v4l2-fh.c +2 -0

@@ -49,6 +49,7 @@ void v4l2_fh_init(struct v4l2_fh *fh, st
 	INIT_LIST_HEAD(&fh->available);
 	INIT_LIST_HEAD(&fh->subscribed);
 	fh->sequence = -1;
+	mutex_init(&fh->subscribe_lock);
 }
 EXPORT_SYMBOL_GPL(v4l2_fh_init);

@@ -93,6 +94,7 @@ void v4l2_fh_exit(struct v4l2_fh *fh)
 	if (fh->vdev == NULL)
 		return;
 	v4l2_event_unsubscribe_all(fh);
+	mutex_destroy(&fh->subscribe_lock);
 	fh->vdev = NULL;
 }
 EXPORT_SYMBOL_GPL(v4l2_fh_exit);

include/media/v4l2-fh.h +1 -0

@@ -43,6 +43,7 @@ struct v4l2_fh {
 	wait_queue_head_t	wait;
 	struct list_head	subscribed; /* Subscribed events */
 	struct list_head	available; /* Dequeueable event */
+	struct mutex		subscribe_lock;
 	unsigned int		navailable;
 	u32			sequence;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #71 lore raw

PATCH 71/120 KVM: PPC: Book3S HV: Dont truncate HPTE index in xlate function

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

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

From: Paul Mackerras <[email protected]>

[ Upstream commit 46dec40fb741f00f1864580130779aeeaf24fb3d ]

This fixes a bug which causes guest virtual addresses to get translated to guest real addresses incorrectly when the guest is using the HPT MMU and has more than 256GB of RAM, or more specifically has a HPT larger than 2GB. This has showed up in testing as a failure of the host to emulate doorbell instructions correctly on POWER9 for HPT guests with more than 256GB of RAM.

The bug is that the HPTE index in kvmppc_mmu_book3s_64_hv_xlate() is stored as an int, and in forming the HPTE address, the index gets shifted left 4 bits as an int before being signed-extended to 64 bits. The simple fix is to make the variable a long int, matching the return type of kvmppc_hv_find_lock_hpte(), which is what calculates the index.

Fixes 697d3899dcb4 ("KVM: PPC: Implement MMIO emulation support for Book3S HV guests")

Signed-off-by Paul Mackerras <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/powerpc/kvm/book3s_64_mmu_hv.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/powerpc/kvm/book3s_64_mmu_hv.c +1 -1

@@ -449,7 +449,7 @@ static int kvmppc_mmu_book3s_64_hv_xlate
 	unsigned long pp, key;
 	unsigned long v, gr;
 	__be64 *hptep;
-	int index;
+	long int index;
 	int virtmode = vcpu->arch.shregs.msr & (data ? MSR_DR : MSR_IR);
 
 	/* Get SLB entry */

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #72 lore raw

PATCH 72/120 mac80211: correct use of IEEE80211_VHT_CAP_RXSTBC_X

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

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

From: Danek Duvall <[email protected]>

[ Upstream commit 67d1ba8a6dc83d90cd58b89fa6cbf9ae35a0cf7f ]

The mod mask for VHT capabilities intends to say that you can override the number of STBC receive streams, and it does, but only by accident. The IEEE80211_VHT_CAP_RXSTBC_X aren't bits to be set, but values (albeit left-shifted). ORing the bits together gets the right answer, but we should use the _MASK macro here instead.

Signed-off-by Danek Duvall <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/mac80211/main.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

net/mac80211/main.c +1 -4

@@ -465,10 +465,7 @@ static const struct ieee80211_vht_cap ma
 		cpu_to_le32(IEEE80211_VHT_CAP_RXLDPC |
 			    IEEE80211_VHT_CAP_SHORT_GI_80 |
 			    IEEE80211_VHT_CAP_SHORT_GI_160 |
-			    IEEE80211_VHT_CAP_RXSTBC_1 |
-			    IEEE80211_VHT_CAP_RXSTBC_2 |
-			    IEEE80211_VHT_CAP_RXSTBC_3 |
-			    IEEE80211_VHT_CAP_RXSTBC_4 |
+			    IEEE80211_VHT_CAP_RXSTBC_MASK |
 			    IEEE80211_VHT_CAP_TXSTBC |
 			    IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE |
 			    IEEE80211_VHT_CAP_SU_BEAMFORMEE_CAPABLE |

Greg Kroah-Hartman

author maintainer

2018-10-11 15:38 UTC #73 lore raw

PATCH 73/120 gpio: adp5588: Fix sleep-in-atomic-context bug

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

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

From: Michael Hennerich <[email protected]>

[ Upstream commit 6537886cdc9a637711fd6da980dbb87c2c87c9aa ]

This fixes:
[BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug

                          in adp5588_gpio_write()
[BUG] gpio: gpio-adp5588: A possible sleep-in-atomic-context bug
                          in adp5588_gpio_direction_input()

Reported-by Jia-Ju Bai <[email protected]>

Signed-off-by Michael Hennerich <[email protected]>

Signed-off-by Linus Walleij <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpio/gpio-adp5588.c |   24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

drivers/gpio/gpio-adp5588.c +20 -4

@@ -41,6 +41,8 @@ struct adp5588_gpio {
 	uint8_t int_en[3];
 	uint8_t irq_mask[3];
 	uint8_t irq_stat[3];
+	uint8_t int_input_en[3];
+	uint8_t int_lvl_cached[3];
 };
 
 static int adp5588_gpio_read(struct i2c_client *client, u8 reg)

@@ -177,12 +179,28 @@ static void adp5588_irq_bus_sync_unlock(
 	struct adp5588_gpio *dev = irq_data_get_irq_chip_data(d);
 	int i;
 
-	for (i = 0; i <= ADP5588_BANK(ADP5588_MAXGPIO); i++)
+	for (i = 0; i <= ADP5588_BANK(ADP5588_MAXGPIO); i++) {
+		if (dev->int_input_en[i]) {
+			mutex_lock(&dev->lock);
+			dev->dir[i] &= ~dev->int_input_en[i];
+			dev->int_input_en[i] = 0;
+			adp5588_gpio_write(dev->client, GPIO_DIR1 + i,
+					   dev->dir[i]);
+			mutex_unlock(&dev->lock);
+		}
+
+		if (dev->int_lvl_cached[i] != dev->int_lvl[i]) {
+			dev->int_lvl_cached[i] = dev->int_lvl[i];
+			adp5588_gpio_write(dev->client, GPIO_INT_LVL1 + i,
+					   dev->int_lvl[i]);
+		}
+
 		if (dev->int_en[i] ^ dev->irq_mask[i]) {
 			dev->int_en[i] = dev->irq_mask[i];
 			adp5588_gpio_write(dev->client, GPIO_INT_EN1 + i,
 					   dev->int_en[i]);
 		}
+	}
 
 	mutex_unlock(&dev->irq_lock);
 }

@@ -225,9 +243,7 @@ static int adp5588_irq_set_type(struct i
 	else
 		return -EINVAL;
 
-	adp5588_gpio_direction_input(&dev->gpio_chip, gpio);
-	adp5588_gpio_write(dev->client, GPIO_INT_LVL1 + bank,
-			   dev->int_lvl[bank]);
+	dev->int_input_en[bank] |= bit;
 
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #74 lore raw

PATCH 74/120 cfg80211: nl80211_update_ft_ies() to validate NL80211_ATTR_IE

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

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

From: Arunk Khandavalli <[email protected]>

[ Upstream commit 4f0223bfe9c3e62d8f45a85f1ef1b18a8a263ef9 ]

nl80211_update_ft_ies() tried to validate NL80211_ATTR_IE with is_valid_ie_attr() before dereferencing it, but that helper function returns true in case of NULL pointer (i.e., attribute not included). This can result to dereferencing a NULL pointer. Fix that by explicitly checking that NL80211_ATTR_IE is included.

Fixes 355199e02b83 ("cfg80211: Extend support for IEEE 802.11r Fast BSS Transition")

Signed-off-by Arunk Khandavalli <[email protected]>

Signed-off-by Jouni Malinen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/wireless/nl80211.c |    1 +
 1 file changed, 1 insertion(+)

net/wireless/nl80211.c +1 -0

@@ -9223,6 +9223,7 @@ static int nl80211_update_ft_ies(struct
 		return -EOPNOTSUPP;
 
 	if (!info->attrs[NL80211_ATTR_MDID] ||
+	    !info->attrs[NL80211_ATTR_IE] ||
 	    !is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
 		return -EINVAL;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #75 lore raw

PATCH 75/120 RAID10 BUG_ON in raise_barrier when force is true and conf->barrier is 0

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

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

From: Xiao Ni <[email protected]>

[ Upstream commit 1d0ffd264204eba1861865560f1f7f7a92919384 ]

In raid10 reshape_request it gets max_sectors in read_balance. If the underlayer disks have bad blocks, the max_sectors is less than last. It will call goto read_more many times. It calls raise_barrier(conf, sectors_done != 0) every time. In this condition sectors_done is not 0. So the value passed to the argument force of raise_barrier is true.

In raise_barrier it checks conf->barrier when force is true. If force is true and conf->barrier is 0, it panic. In this case reshape_request submits bio to under layer disks. And in the callback function of the bio it calls lower_barrier. If the bio finishes before calling raise_barrier again, it can trigger the BUG_ON.

Add one pair of raise_barrier/lower_barrier to fix this bug.

Signed-off-by Xiao Ni <[email protected]>

Signed-off-by Shaohua Li <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/raid10.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/md/raid10.c +4 -1

@@ -4423,11 +4423,12 @@ static sector_t reshape_request(struct m
 		allow_barrier(conf);
 	}
 
+	raise_barrier(conf, 0);
 read_more:
 	/* Now schedule reads for blocks from sector_nr to last */
 	r10_bio = mempool_alloc(conf->r10buf_pool, GFP_NOIO);
 	r10_bio->state = 0;
-	raise_barrier(conf, sectors_done != 0);
+	raise_barrier(conf, 1);
 	atomic_set(&r10_bio->remaining, 0);
 	r10_bio->mddev = mddev;
 	r10_bio->sector = sector_nr;

@@ -4532,6 +4533,8 @@ bio_full:
 	if (sector_nr <= last)
 		goto read_more;
 
+	lower_barrier(conf);
+
 	/* Now that we have done the whole section we can
 	 * update reshape_progress
 	 */

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #76 lore raw

PATCH 76/120 net: cadence: Fix a sleep-in-atomic-context bug in macb_halt_tx()

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

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

From: Jia-Ju Bai <[email protected]>

[ Upstream commit 16fe10cf92783ed9ceb182d6ea2b8adf5e8ec1b8 ]

The kernel module may sleep with holding a spinlock.

The function call paths (from bottom to top) in Linux-4.16 are:

[FUNC] usleep_range drivers/net/ethernet/cadence/macb_main.c, 648:
usleep_range in macb_halt_tx
drivers/net/ethernet/cadence/macb_main.c, 730:
macb_halt_tx in macb_tx_error_task
drivers/net/ethernet/cadence/macb_main.c, 721:
_raw_spin_lock_irqsave in macb_tx_error_task

To fix this bug, usleep_range() is replaced with udelay().

This bug is found by my static analysis tool DSAC.

Signed-off-by Jia-Ju Bai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/cadence/macb.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/cadence/macb.c +1 -1

@@ -464,7 +464,7 @@ static int macb_halt_tx(struct macb *bp)
 		if (!(status & MACB_BIT(TGO)))
 			return 0;
 
-		usleep_range(10, 250);
+		udelay(250);
 	} while (time_before(halt_time, timeout));
 
 	return -ETIMEDOUT;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:34 UTC #77 lore raw

PATCH 77/120 fs/cifs: dont translate SFM_SLASH (U+F026) to backslash

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

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

From: Jon Kuhn <[email protected]>

[ Upstream commit c15e3f19a6d5c89b1209dc94b40e568177cb0921 ]

When a Mac client saves an item containing a backslash to a file server the backslash is represented in the CIFS/SMB protocol as as U+F026. Before this change, listing a directory containing an item with a backslash in its name will return that item with the backslash represented with a true backslash character (U+005C) because convert_sfm_character mapped U+F026 to U+005C when interpretting the CIFS/SMB protocol response. However, attempting to open or stat the path using a true backslash will result in an error because convert_to_sfm_char does not map U+005C back to U+F026 causing the CIFS/SMB request to be made with the backslash represented as U+005C.

This change simply prevents the U+F026 to U+005C conversion from happenning. This is analogous to how the code does not do any translation of UNI_SLASH (U+F000).

Signed-off-by Jon Kuhn <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/cifs_unicode.c |    3 ---
 1 file changed, 3 deletions(-)

fs/cifs/cifs_unicode.c +0 -3

@@ -136,9 +136,6 @@ convert_sfm_char(const __u16 src_char, c
 	case SFM_LESSTHAN:
 		*target = '<';
 		break;
-	case SFM_SLASH:
-		*target = '\\';
-		break;
 	case SFM_SPACE:
 		*target = ' ';
 		break;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #78 lore raw

PATCH 78/120 mac80211: fix a race between restart and CSA flows

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

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

From: Emmanuel Grumbach <[email protected]>

[ Upstream commit f3ffb6c3a28963657eb8b02a795d75f2ebbd5ef4 ]

We hit a problem with iwlwifi that was caused by a bug in mac80211. A bug in iwlwifi caused the firwmare to crash in certain cases in channel switch. Because of that bug, drv_pre_channel_switch would fail and trigger the restart flow.
Now we had the hw restart worker which runs on the system's workqueue and the csa_connection_drop_work worker that runs on mac80211's workqueue that can run together. This is obviously problematic since the restart work wants to reconfigure the connection, while the csa_connection_drop_work worker does the exact opposite: it tries to disconnect.

Fix this by cancelling the csa_connection_drop_work worker in the restart worker.

Note that this can sound racy: we could have:

driver iface_work CSA_work restart_work
+++++++++++++++++++++++++++++++++++++++++++++

              |
 <--drv_cs ---|
<FW CRASH!>
-CS FAILED-->
              |                       |
              |                 cancel_work(CSA)
           schedule                   |
           CSA work                   |
                         |            |

Race between those 2

But this is not possible because we flush the workqueue in the restart worker before we cancel the CSA worker. That would be bullet proof if we could guarantee that we schedule the CSA worker only from the iface_work which runs on the workqueue (and not on the system's workqueue), but unfortunately we do have an instance in which we schedule the CSA work outside the context of the workqueue (ieee80211_chswitch_done).

Note also that we should probably cancel other workers like beacon_connection_loss_work and possibly others for different types of interfaces, at the very least, IBSS should suffer from the exact same problem, but for now, do the minimum to fix the actual bug that was actually experienced and reproduced.

Signed-off-by Emmanuel Grumbach <[email protected]>

Signed-off-by Luca Coelho <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/mac80211/main.c |   21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

net/mac80211/main.c +20 -1

@@ -258,8 +258,27 @@ static void ieee80211_restart_work(struc
 	     "%s called with hardware scan in progress\n", __func__);
 
 	rtnl_lock();
-	list_for_each_entry(sdata, &local->interfaces, list)
+	list_for_each_entry(sdata, &local->interfaces, list) {
+		/*
+		 * XXX: there may be more work for other vif types and even
+		 * for station mode: a good thing would be to run most of
+		 * the iface type's dependent _stop (ieee80211_mg_stop,
+		 * ieee80211_ibss_stop) etc...
+		 * For now, fix only the specific bug that was seen: race
+		 * between csa_connection_drop_work and us.
+		 */
+		if (sdata->vif.type == NL80211_IFTYPE_STATION) {
+			/*
+			 * This worker is scheduled from the iface worker that
+			 * runs on mac80211's workqueue, so we can't be
+			 * scheduling this worker after the cancel right here.
+			 * The exception is ieee80211_chswitch_done.
+			 * Then we can have a race...
+			 */
+			cancel_work_sync(&sdata->u.mgd.csa_connection_drop_work);
+		}
 		flush_delayed_work(&sdata->dec_tailroom_needed_wk);
+	}
 	ieee80211_scan_cancel(local);
 	ieee80211_reconfig(local);
 	rtnl_unlock();

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #79 lore raw

PATCH 79/120 mac80211: Fix station bandwidth setting after channel switch

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

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

From: Ilan Peer <[email protected]>

[ Upstream commit 0007e94355fdb71a1cf5dba0754155cba08f0666 ]

When performing a channel switch flow for a managed interface, the flow did not update the bandwidth of the AP station and the rate scale algorithm. In case of a channel width downgrade, this would result with the rate scale algorithm using a bandwidth that does not match the interface channel configuration.

Fix this by updating the AP station bandwidth and rate scaling algorithm before the actual channel change in case of a bandwidth downgrade, or after the actual channel change in case of a bandwidth upgrade.

Signed-off-by Ilan Peer <[email protected]>

Signed-off-by Luca Coelho <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/mac80211/mlme.c |   53 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

net/mac80211/mlme.c +53 -0

@@ -970,6 +970,10 @@ static void ieee80211_chswitch_work(stru
 	 */
 
 	if (sdata->reserved_chanctx) {
+		struct ieee80211_supported_band *sband = NULL;
+		struct sta_info *mgd_sta = NULL;
+		enum ieee80211_sta_rx_bandwidth bw = IEEE80211_STA_RX_BW_20;
+
 		/*
 		 * with multi-vif csa driver may call ieee80211_csa_finish()
 		 * many times while waiting for other interfaces to use their

@@ -978,6 +982,48 @@ static void ieee80211_chswitch_work(stru
 		if (sdata->reserved_ready)
 			goto out;
 
+		if (sdata->vif.bss_conf.chandef.width !=
+		    sdata->csa_chandef.width) {
+			/*
+			 * For managed interface, we need to also update the AP
+			 * station bandwidth and align the rate scale algorithm
+			 * on the bandwidth change. Here we only consider the
+			 * bandwidth of the new channel definition (as channel
+			 * switch flow does not have the full HT/VHT/HE
+			 * information), assuming that if additional changes are
+			 * required they would be done as part of the processing
+			 * of the next beacon from the AP.
+			 */
+			switch (sdata->csa_chandef.width) {
+			case NL80211_CHAN_WIDTH_20_NOHT:
+			case NL80211_CHAN_WIDTH_20:
+			default:
+				bw = IEEE80211_STA_RX_BW_20;
+				break;
+			case NL80211_CHAN_WIDTH_40:
+				bw = IEEE80211_STA_RX_BW_40;
+				break;
+			case NL80211_CHAN_WIDTH_80:
+				bw = IEEE80211_STA_RX_BW_80;
+				break;
+			case NL80211_CHAN_WIDTH_80P80:
+			case NL80211_CHAN_WIDTH_160:
+				bw = IEEE80211_STA_RX_BW_160;
+				break;
+			}
+
+			mgd_sta = sta_info_get(sdata, ifmgd->bssid);
+			sband =
+				local->hw.wiphy->bands[sdata->csa_chandef.chan->band];
+		}
+
+		if (sdata->vif.bss_conf.chandef.width >
+		    sdata->csa_chandef.width) {
+			mgd_sta->sta.bandwidth = bw;
+			rate_control_rate_update(local, sband, mgd_sta,
+						 IEEE80211_RC_BW_CHANGED);
+		}
+
 		ret = ieee80211_vif_use_reserved_context(sdata);
 		if (ret) {
 			sdata_info(sdata,

@@ -988,6 +1034,13 @@ static void ieee80211_chswitch_work(stru
 			goto out;
 		}
 
+		if (sdata->vif.bss_conf.chandef.width <
+		    sdata->csa_chandef.width) {
+			mgd_sta->sta.bandwidth = bw;
+			rate_control_rate_update(local, sband, mgd_sta,
+						 IEEE80211_RC_BW_CHANGED);
+		}
+
 		goto out;
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #80 lore raw

PATCH 80/120 mac80211: shorten the IBSS debug messages

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

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

From: Emmanuel Grumbach <[email protected]>

[ Upstream commit c6e57b3896fc76299913b8cfd82d853bee8a2c84 ]

When tracing is enabled, all the debug messages are recorded and must not exceed MAX_MSG_LEN (100) columns. Longer debug messages grant the user with:

WARNING: CPU: 3 PID: 32642 at /tmp/wifi-core-20180806094828/src/iwlwifi-stack-dev/net/mac80211/./trace_msg.h:32 trace_event_raw_event_mac80211_msg_event+0xab/0xc0 [mac80211]
Workqueue: phy1 ieee80211_iface_work [mac80211]
 RIP: 0010:trace_event_raw_event_mac80211_msg_event+0xab/0xc0 [mac80211]
 Call Trace:
  __sdata_dbg+0xbd/0x120 [mac80211]
  ieee80211_ibss_rx_queued_mgmt+0x15f/0x510 [mac80211]
  ieee80211_iface_work+0x21d/0x320 [mac80211]

Signed-off-by Emmanuel Grumbach <[email protected]>

Signed-off-by Luca Coelho <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/mac80211/ibss.c |   22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

net/mac80211/ibss.c +11 ~~-11~~

@@ -944,8 +944,8 @@ static void ieee80211_rx_mgmt_deauth_ibs
 	if (len < IEEE80211_DEAUTH_FRAME_LEN)
 		return;
 
-	ibss_dbg(sdata, "RX DeAuth SA=%pM DA=%pM BSSID=%pM (reason: %d)\n",
-		 mgmt->sa, mgmt->da, mgmt->bssid, reason);
+	ibss_dbg(sdata, "RX DeAuth SA=%pM DA=%pM\n", mgmt->sa, mgmt->da);
+	ibss_dbg(sdata, "\tBSSID=%pM (reason: %d)\n", mgmt->bssid, reason);
 	sta_info_destroy_addr(sdata, mgmt->sa);
 }

@@ -963,9 +963,9 @@ static void ieee80211_rx_mgmt_auth_ibss(
 	auth_alg = le16_to_cpu(mgmt->u.auth.auth_alg);
 	auth_transaction = le16_to_cpu(mgmt->u.auth.auth_transaction);
 
-	ibss_dbg(sdata,
-		 "RX Auth SA=%pM DA=%pM BSSID=%pM (auth_transaction=%d)\n",
-		 mgmt->sa, mgmt->da, mgmt->bssid, auth_transaction);
+	ibss_dbg(sdata, "RX Auth SA=%pM DA=%pM\n", mgmt->sa, mgmt->da);
+	ibss_dbg(sdata, "\tBSSID=%pM (auth_transaction=%d)\n",
+		 mgmt->bssid, auth_transaction);
 
 	if (auth_alg != WLAN_AUTH_OPEN || auth_transaction != 1)
 		return;

@@ -1130,10 +1130,10 @@ static void ieee80211_rx_bss_info(struct
 		rx_timestamp = drv_get_tsf(local, sdata);
 	}
 
-	ibss_dbg(sdata,
-		 "RX beacon SA=%pM BSSID=%pM TSF=0x%llx BCN=0x%llx diff=%lld @%lu\n",
+	ibss_dbg(sdata, "RX beacon SA=%pM BSSID=%pM TSF=0x%llx\n",
 		 mgmt->sa, mgmt->bssid,
-		 (unsigned long long)rx_timestamp,
+		 (unsigned long long)rx_timestamp);
+	ibss_dbg(sdata, "\tBCN=0x%llx diff=%lld @%lu\n",
 		 (unsigned long long)beacon_timestamp,
 		 (unsigned long long)(rx_timestamp - beacon_timestamp),
 		 jiffies);

@@ -1414,9 +1414,9 @@ static void ieee80211_rx_mgmt_probe_req(
 
 	tx_last_beacon = drv_tx_last_beacon(local);
 
-	ibss_dbg(sdata,
-		 "RX ProbeReq SA=%pM DA=%pM BSSID=%pM (tx_last_beacon=%d)\n",
-		 mgmt->sa, mgmt->da, mgmt->bssid, tx_last_beacon);
+	ibss_dbg(sdata, "RX ProbeReq SA=%pM DA=%pM\n", mgmt->sa, mgmt->da);
+	ibss_dbg(sdata, "\tBSSID=%pM (tx_last_beacon=%d)\n",
+		 mgmt->bssid, tx_last_beacon);
 
 	if (!tx_last_beacon && is_multicast_ether_addr(mgmt->da))
 		return;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #81 lore raw

PATCH 81/120 tools/vm/slabinfo.c: fix sign-compare warning

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

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

From: Naoya Horiguchi <[email protected]>

[ Upstream commit 904506562e0856f2535d876407d087c9459d345b ]

Currently we get the following compiler warning:

    slabinfo.c:854:22: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
       if (s->object_size < min_objsize)
                          ^

due to the mismatch of signed/unsigned comparison. ->object_size and ->slab_size are never expected to be negative, so let's define them as unsigned int.

[[email protected]: convert everything - none of these can be negative]

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Naoya Horiguchi <[email protected]>

Reviewed-by Andrew Morton <[email protected]>

Cc Matthew Wilcox <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/vm/slabinfo.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

tools/vm/slabinfo.c +2 -2

@@ -29,8 +29,8 @@ struct slabinfo {
 	int alias;
 	int refs;
 	int aliases, align, cache_dma, cpu_slabs, destroy_by_rcu;
-	int hwcache_align, object_size, objs_per_slab;
-	int sanity_checks, slab_size, store_user, trace;
+	unsigned int hwcache_align, object_size, objs_per_slab;
+	unsigned int sanity_checks, slab_size, store_user, trace;
 	int order, poison, reclaim_account, red_zone;
 	unsigned long partial, objects, slabs, objects_partial, objects_total;
 	unsigned long alloc_fastpath, alloc_slowpath;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #82 lore raw

PATCH 82/120 tools/vm/page-types.c: fix "defined but not used" warning

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

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

From: Naoya Horiguchi <[email protected]>

[ Upstream commit 7ab660f8baecfe26c1c267fa8e64d2073feae2bb ]

debugfs_known_mountpoints[] is not used any more, so let's remove it.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Naoya Horiguchi <[email protected]>

Reviewed-by Andrew Morton <[email protected]>

Cc Matthew Wilcox <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 tools/vm/page-types.c |    6 ------
 1 file changed, 6 deletions(-)

tools/vm/page-types.c +0 -6

@@ -151,12 +151,6 @@ static const char * const page_flag_name
 };
 
 
-static const char * const debugfs_known_mountpoints[] = {
-	"/sys/kernel/debug",
-	"/debug",
-	0,
-};
-
 /*
  * data structures
  */

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #83 lore raw

PATCH 83/120 mm: madvise(MADV_DODUMP): allow hugetlbfs pages

Link https://lists.launchpad.net/maria-discuss/msg05245.html

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

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

From: Daniel Black <[email protected]>

commit d41aa5252394c065d1f04d1ceea885b70d00c9c6 upstream.

Reproducer, assuming 2M of hugetlbfs available:

Hugetlbfs mounted, size=2M and option user=testuser

  # mount | grep ^hugetlbfs
  hugetlbfs on /dev/hugepages type hugetlbfs (rw,pagesize=2M,user=dan)
  # sysctl vm.nr_hugepages=1
  vm.nr_hugepages = 1
  # grep Huge /proc/meminfo
  AnonHugePages:         0 kB
  ShmemHugePages:        0 kB
  HugePages_Total:       1
  HugePages_Free:        1
  HugePages_Rsvd:        0
  HugePages_Surp:        0
  Hugepagesize:       2048 kB
  Hugetlb:            2048 kB

Code:

  #include <sys/mman.h>
  #include <stddef.h>
  #define SIZE 2*1024*1024
  int main()
  {
    void *ptr;
    ptr = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_HUGETLB | MAP_ANONYMOUS, -1, 0);
    madvise(ptr, SIZE, MADV_DONTDUMP);
    madvise(ptr, SIZE, MADV_DODUMP);
  }

Compile and strace:

mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0) = 0x7ff7c9200000 madvise(0x7ff7c9200000, 2097152, MADV_DONTDUMP) = 0
madvise(0x7ff7c9200000, 2097152, MADV_DODUMP) = -1 EINVAL (Invalid argument)

hugetlbfs pages have VM_DONTEXPAND in the VmFlags driver pages based on author testing with analysis from Florian Weimer[1].

The inclusion of VM_DONTEXPAND into the VM_SPECIAL defination was a consequence of the large useage of VM_DONTEXPAND in device drivers.

A consequence of [2] is that VM_DONTEXPAND marked pages are unable to be marked DODUMP.

A user could quite legitimately madvise(MADV_DONTDUMP) their hugetlbfs memory for a while and later request that madvise(MADV_DODUMP) on the same memory. We correct this omission by allowing madvice(MADV_DODUMP) on hugetlbfs pages.

[1] https://stackoverflow.com/questions/52548260/madvisedodump-on-the-same-ptr-size-as-a-successful-madvisedontdump-fails-wit
[2] commit 0103bd16fb90 ("mm: prepare VM_DONTDUMP for using in drivers")

Link http://lkml.kernel.org/r/[email protected] open here

Fixes 0103bd16fb90 ("mm: prepare VM_DONTDUMP for using in drivers")

Reported-by Kenneth Penza <[email protected]>

Signed-off-by Daniel Black <[email protected]>

Reviewed-by Mike Kravetz <[email protected]>

Cc Konstantin Khlebnikov <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

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

mm/madvise.c +1 -1

@@ -75,7 +75,7 @@ static long madvise_behavior(struct vm_a
 		new_flags |= VM_DONTDUMP;
 		break;
 	case MADV_DODUMP:
-		if (new_flags & VM_SPECIAL) {
+		if (!is_vm_hugetlb_page(vma) && new_flags & VM_SPECIAL) {
 			error = -EINVAL;
 			goto out;
 		}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #84 lore raw

PATCH 84/120 RDMA/ucma: check fd type in ucma_migrate_id()

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

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

From: Jann Horn <[email protected]>

[ Upstream commit 0d23ba6034b9cf48b8918404367506da3e4b3ee5 ]

The current code grabs the private_data of whatever file descriptor userspace has supplied and implicitly casts it to a struct ucma_file *, potentially causing a type confusion.

This is probably fine in practice because the pointer is only used for comparisons, it is never actually dereferenced; and even in the comparisons, it is unlikely that a file from another filesystem would have a ->private_data pointer that happens to also be valid in this context. But ->private_data is not always guaranteed to be a valid pointer to an object owned by the file's filesystem; for example, some filesystems just cram numbers in there.

Check the type of the supplied file descriptor to be safe, analogous to how other places in the kernel do it.

Fixes 88314e4dda1e ("RDMA/cma: add support for rdma_migrate_id()")

Signed-off-by Jann Horn <[email protected]>

Signed-off-by Jason Gunthorpe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/core/ucma.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/infiniband/core/ucma.c +6 -0

@@ -113,6 +113,8 @@ static DEFINE_MUTEX(mut);
 static DEFINE_IDR(ctx_idr);
 static DEFINE_IDR(multicast_idr);
 
+static const struct file_operations ucma_fops;
+
 static inline struct ucma_context *_ucma_find_context(int id,
 						      struct ucma_file *file)
 {

@@ -1416,6 +1418,10 @@ static ssize_t ucma_migrate_id(struct uc
 	f = fdget(cmd.fd);
 	if (!f.file)
 		return -ENOENT;
+	if (f.file->f_op != &ucma_fops) {
+		ret = -EINVAL;
+		goto file_put;
+	}
 
 	/* Validate current fd and prevent destruction of id. */
 	ctx = ucma_get_ctx(f.file->private_data, cmd.id);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #85 lore raw

PATCH 85/120 USB: yurex: Check for truncation in yurex_read()

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

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

From: Ben Hutchings <[email protected]>

[ Upstream commit 14427b86837a4baf1c121934c6599bdb67dfa9fc ]

snprintf() always returns the full length of the string it could have printed, even if it was truncated because the buffer was too small. So in case the counter value is truncated, we will over-read from in_buffer and over-write to the caller's buffer.

I don't think it's actually possible for this to happen, but in case truncation occurs, WARN and return -EIO.

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/misc/yurex.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/usb/misc/yurex.c +3 -0

@@ -430,6 +430,9 @@ static ssize_t yurex_read(struct file *f
 	spin_unlock_irqrestore(&dev->lock, flags);
 	mutex_unlock(&dev->io_mutex);
 
+	if (WARN_ON_ONCE(len >= sizeof(in_buffer)))
+		return -EIO;
+
 	return simple_read_from_buffer(buffer, count, ppos, in_buffer, len);
 }

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #86 lore raw

PATCH 86/120 fs/cifs: suppress a string overflow warning

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

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

From: Stephen Rothwell <[email protected]>

[ Upstream commit bcfb84a996f6fa90b5e6e2954b2accb7a4711097 ]

A powerpc build of cifs with gcc v8.2.0 produces this warning:

fs/cifs/cifssmb.c: In function ‘CIFSSMBNegotiate’:
fs/cifs/cifssmb.c:605:3: warning: ‘strncpy’ writing 16 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=]
strncpy(pSMB->DialectsArray+count, protocols[i].name, 16); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Since we are already doing a strlen() on the source, change the strncpy to a memcpy().

Signed-off-by Stephen Rothwell <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/cifssmb.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

fs/cifs/cifssmb.c +8 -3

@@ -577,10 +577,15 @@ CIFSSMBNegotiate(const unsigned int xid,
 	}
 
 	count = 0;
+	/*
+	 * We know that all the name entries in the protocols array
+	 * are short (< 16 bytes anyway) and are NUL terminated.
+	 */
 	for (i = 0; i < CIFS_NUM_PROT; i++) {
-		strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
-		count += strlen(protocols[i].name) + 1;
-		/* null at end of source and target buffers anyway */
+		size_t len = strlen(protocols[i].name) + 1;
+
+		memcpy(pSMB->DialectsArray+count, protocols[i].name, len);
+		count += len;
 	}
 	inc_rfc1001_len(pSMB, count);
 	pSMB->ByteCount = cpu_to_le16(count);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #87 lore raw

PATCH 87/120 dm thin metadata: try to avoid ever aborting transactions

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

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

From: Joe Thornber <[email protected]>

[ Upstream commit 3ab91828166895600efd9cdc3a0eb32001f7204a ]

Committing a transaction can consume some metadata of it's own, we now reserve a small amount of metadata to cover this. Free metadata reported by the kernel will not include this reserve.

If any of the reserve has been used after a commit we enter a new internal state PM_OUT_OF_METADATA_SPACE. This is reported as PM_READ_ONLY, so no userland changes are needed. If the metadata device is resized the pool will move back to PM_WRITE.

These changes mean we never need to abort and rollback a transaction due to running out of metadata space. This is particularly important because there have been a handful of reports of data corruption against DM thin-provisioning that can all be attributed to the thin-pool having ran out of metadata space.

Signed-off-by Joe Thornber <[email protected]>

Signed-off-by Mike Snitzer <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm-thin-metadata.c |   36 ++++++++++++++++++++
 drivers/md/dm-thin.c          |   73 +++++++++++++++++++++++++++++++++++++-----
 2 files changed, 100 insertions(+), 9 deletions(-)

drivers/md/dm-thin-metadata.c +35 -1

@@ -191,6 +191,12 @@ struct dm_pool_metadata {
 	bool read_only:1;
 
 	/*
+	 * We reserve a section of the metadata for commit overhead.
+	 * All reported space does *not* include this.
+	 */
+	dm_block_t metadata_reserve;
+
+	/*
 	 * Set if a transaction has to be aborted but the attempt to roll back
 	 * to the previous (good) transaction failed.  The only pool metadata
 	 * operation possible in this state is the closing of the device.

@@ -824,6 +830,22 @@ static int __commit_transaction(struct d
 	return dm_tm_commit(pmd->tm, sblock);
 }
 
+static void __set_metadata_reserve(struct dm_pool_metadata *pmd)
+{
+	int r;
+	dm_block_t total;
+	dm_block_t max_blocks = 4096; /* 16M */
+
+	r = dm_sm_get_nr_blocks(pmd->metadata_sm, &total);
+	if (r) {
+		DMERR("could not get size of metadata device");
+		pmd->metadata_reserve = max_blocks;
+	} else {
+		sector_div(total, 10);
+		pmd->metadata_reserve = min(max_blocks, total);
+	}
+}
+
 struct dm_pool_metadata *dm_pool_metadata_open(struct block_device *bdev,
 					       sector_t data_block_size,
 					       bool format_device)

@@ -858,6 +880,8 @@ struct dm_pool_metadata *dm_pool_metadat
 		return ERR_PTR(r);
 	}
 
+	__set_metadata_reserve(pmd);
+
 	return pmd;
 }

@@ -1625,6 +1649,13 @@ int dm_pool_get_free_metadata_block_coun
 	down_read(&pmd->root_lock);
 	if (!pmd->fail_io)
 		r = dm_sm_get_nr_free(pmd->metadata_sm, result);
+
+	if (!r) {
+		if (*result < pmd->metadata_reserve)
+			*result = 0;
+		else
+			*result -= pmd->metadata_reserve;
+	}
 	up_read(&pmd->root_lock);
 
 	return r;

@@ -1746,8 +1777,11 @@ int dm_pool_resize_metadata_dev(struct d
 	int r = -EINVAL;
 
 	down_write(&pmd->root_lock);
-	if (!pmd->fail_io)
+	if (!pmd->fail_io) {
 		r = __resize_space_map(pmd->metadata_sm, new_count);
+		if (!r)
+			__set_metadata_reserve(pmd);
+	}
 	up_write(&pmd->root_lock);
 
 	return r;

drivers/md/dm-thin.c +65 -8

141 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2018-10-11 15:34 UTC #88 lore raw

PATCH 88/120 arch/hexagon: fix kernel/dma.c build warning

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

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

From: Randy Dunlap <[email protected]>

[ Upstream commit 200f351e27f014fcbf69b544b0b4b72aeaf45fd3 ]

Fix build warning in arch/hexagon/kernel/dma.c by casting a void * to unsigned long to match the function parameter type.

../arch/hexagon/kernel/dma.c: In function 'arch_dma_alloc':
../arch/hexagon/kernel/dma.c:51:5: warning: passing argument 2 of 'gen_pool_add' makes integer from pointer without a cast [enabled by default] ../include/linux/genalloc.h:112:19: note: expected 'long unsigned int' but argument is of type 'void *'

Signed-off-by Randy Dunlap <[email protected]>

Cc Yoshinori Sato <[email protected]>

Cc Rich Felker <[email protected]>

Patch-mainline: linux-kernel @ 07/20/2018, 20:17

[[email protected]: fixed architecture name]

Signed-off-by Richard Kuo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/hexagon/kernel/dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/hexagon/kernel/dma.c +1 -1

@@ -79,7 +79,7 @@ static void *hexagon_dma_alloc_coherent(
 			panic("Can't create %s() memory pool!", __func__);
 		else
 			gen_pool_add(coherent_pool,
-				pfn_to_virt(max_low_pfn),
+				(unsigned long)pfn_to_virt(max_low_pfn),
 				hexagon_coherent_pool_size, -1);
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:34 UTC #89 lore raw

PATCH 89/120 hexagon: modify ffs() and fls() to return int

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

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

From: Randy Dunlap <[email protected]>

[ Upstream commit 5c41aaad409c097cf1ef74f2c649fed994744ef5 ]

Building drivers/mtd/nand/raw/nandsim.c on arch/hexagon/ produces a printk format build warning. This is due to hexagon's ffs() being coded as returning long instead of int.

Fix the printk format warning by changing all of hexagon's ffs() and fls() functions to return int instead of long. The variables that they return are already int instead of long. This return type matches the return type in <asm-generic/bitops/>.

../drivers/mtd/nand/raw/nandsim.c: In function 'init_nandsim':
../drivers/mtd/nand/raw/nandsim.c:760:2: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'long int' [-Wformat]

There are no ffs() or fls() allmodconfig build errors after making this change.

Signed-off-by Randy Dunlap <[email protected]>

Cc Richard Kuo <[email protected]>

Cc Geert Uytterhoeven <[email protected]>

Patch-mainline: linux-kernel @ 07/22/2018, 16:03

Signed-off-by Richard Kuo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/hexagon/include/asm/bitops.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/hexagon/include/asm/bitops.h +2 -2

@@ -211,7 +211,7 @@ static inline long ffz(int x)
  * This is defined the same way as ffs.
  * Note fls(0) = 0, fls(1) = 1, fls(0x80000000) = 32.
  */
-static inline long fls(int x)
+static inline int fls(int x)
 {
 	int r;

@@ -232,7 +232,7 @@ static inline long fls(int x)
  * the libc and compiler builtin ffs routines, therefore
  * differs in spirit from the above ffz (man ffs).
  */
-static inline long ffs(int x)
+static inline int ffs(int x)
 {
 	int r;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #90 lore raw

PATCH 90/120 r8169: Clear RTL_FLAG_TASK_*_PENDING when clearing RTL_FLAG_TASK_ENABLED

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

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

From: Kai-Heng Feng <[email protected]>

[ Upstream commit 6ad569019999300afd8e614d296fdc356550b77f ]

After system suspend, sometimes the r8169 doesn't work when ethernet cable gets pluggued.

This issue happens because rtl_reset_work() doesn't get called from rtl8169_runtime_resume(), after system suspend.

In rtl_task(), RTL_FLAG_TASK_* only gets cleared if this condition is met:
if (!netif_running(dev) ||

    !test_bit(RTL_FLAG_TASK_ENABLED, tp->wk.flags))
    ...

If RTL_FLAG_TASK_ENABLED was cleared during system suspend while RTL_FLAG_TASK_RESET_PENDING was set, the next rtl_schedule_task() won't schedule task as the flag is still there.

So in addition to clearing RTL_FLAG_TASK_ENABLED, also clears other flags.

Cc Heiner Kallweit <[email protected]>

Signed-off-by Kai-Heng Feng <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/net/ethernet/realtek/r8169.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

drivers/net/ethernet/realtek/r8169.c +6 -3

@@ -749,7 +749,7 @@ struct rtl8169_counters {
 };
 
 enum rtl_flag {
-	RTL_FLAG_TASK_ENABLED,
+	RTL_FLAG_TASK_ENABLED = 0,
 	RTL_FLAG_TASK_SLOW_PENDING,
 	RTL_FLAG_TASK_RESET_PENDING,
 	RTL_FLAG_TASK_PHY_PENDING,

@@ -7523,7 +7523,8 @@ static int rtl8169_close(struct net_devi
 	rtl8169_update_counters(dev);
 
 	rtl_lock_work(tp);
-	clear_bit(RTL_FLAG_TASK_ENABLED, tp->wk.flags);
+	/* Clear all task flags */
+	bitmap_zero(tp->wk.flags, RTL_FLAG_MAX);
 
 	rtl8169_down(dev);
 	rtl_unlock_work(tp);

@@ -7679,7 +7680,9 @@ static void rtl8169_net_suspend(struct n
 
 	rtl_lock_work(tp);
 	napi_disable(&tp->napi);
-	clear_bit(RTL_FLAG_TASK_ENABLED, tp->wk.flags);
+	/* Clear all task flags */
+	bitmap_zero(tp->wk.flags, RTL_FLAG_MAX);
+
 	rtl_unlock_work(tp);
 
 	rtl_pll_power_down(tp);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #91 lore raw

PATCH 91/120 s390/qeth: dont dump past end of unknown HW header

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

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

From: Julian Wiedmann <[email protected]>

[ Upstream commit 0ac1487c4b2de383b91ecad1be561b8f7a2c15f4 ]

For inbound data with an unsupported HW header format, only dump the actual HW header. We have no idea how much payload follows it, and what it contains. Worst case, we dump past the end of the Inbound Buffer and access whatever is located next in memory.

Signed-off-by Julian Wiedmann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/s390/net/qeth_l2_main.c |    2 +-
 drivers/s390/net/qeth_l3_main.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

drivers/s390/net/qeth_l2_main.c +1 -1

@@ -452,7 +452,7 @@ static int qeth_l2_process_inbound_buffe
 		default:
 			dev_kfree_skb_any(skb);
 			QETH_CARD_TEXT(card, 3, "inbunkno");
-			QETH_DBF_HEX(CTRL, 3, hdr, QETH_DBF_CTRL_LEN);
+			QETH_DBF_HEX(CTRL, 3, hdr, sizeof(*hdr));
 			continue;
 		}
 		work_done++;

drivers/s390/net/qeth_l3_main.c +1 -1

@@ -1993,7 +1993,7 @@ static int qeth_l3_process_inbound_buffe
 		default:
 			dev_kfree_skb_any(skb);
 			QETH_CARD_TEXT(card, 3, "inbunkno");
-			QETH_DBF_HEX(CTRL, 3, hdr, QETH_DBF_CTRL_LEN);
+			QETH_DBF_HEX(CTRL, 3, hdr, sizeof(*hdr));
 			continue;
 		}
 		work_done++;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #92 lore raw

PATCH 92/120 cifs: read overflow in is_valid_oplock_break()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 097f5863b1a0c9901f180bbd56ae7d630655faaa ]

We need to verify that the "data_offset" is within bounds.

Reported-by Dr Silvio Cesare of InfoSect <[email protected]>

Signed-off-by Dan Carpenter <[email protected]>

Reviewed-by Aurelien Aptel <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/misc.c |    8 ++++++++
 1 file changed, 8 insertions(+)

fs/cifs/misc.c +8 -0

@@ -405,9 +405,17 @@ is_valid_oplock_break(char *buffer, stru
 			(struct smb_com_transaction_change_notify_rsp *)buf;
 		struct file_notify_information *pnotify;
 		__u32 data_offset = 0;
+		size_t len = srv->total_read - sizeof(pSMBr->hdr.smb_buf_length);
+
 		if (get_bcc(buf) > sizeof(struct file_notify_information)) {
 			data_offset = le32_to_cpu(pSMBr->DataOffset);
 
+			if (data_offset >
+			    len - sizeof(struct file_notify_information)) {
+				cifs_dbg(FYI, "invalid data_offset %u\n",
+					 data_offset);
+				return true;
+			}
 			pnotify = (struct file_notify_information *)
 				((char *)&pSMBr->hdr.Protocol + data_offset);
 			cifs_dbg(FYI, "dnotify on %s Action: 0x%x\n",

Greg Kroah-Hartman

author maintainer

2018-10-11 15:39 UTC #93 lore raw

PATCH 93/120 xen/manage: dont complain about an empty value in control/sysrq node

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

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

From: Vitaly Kuznetsov <[email protected]>

[ Upstream commit 87dffe86d406bee8782cac2db035acb9a28620a7 ]

When guest receives a sysrq request from the host it acknowledges it by writing '\0' to control/sysrq xenstore node. This, however, make xenstore watch fire again but xenbus_scanf() fails to parse empty value with "%c" format string:

sysrq: SysRq : Emergency Sync
Emergency Sync complete
xen:manage: Error -34 reading sysrq code in control/sysrq

Ignore -ERANGE the same way we already ignore -ENOENT, empty value in control/sysrq is totally legal.

Signed-off-by Vitaly Kuznetsov <[email protected]>

Reviewed-by Wei Liu <[email protected]>

Signed-off-by Boris Ostrovsky <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/xen/manage.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/xen/manage.c +4 -2

@@ -277,9 +277,11 @@ static void sysrq_handler(struct xenbus_
 		/*
 		 * The Xenstore watch fires directly after registering it and
 		 * after a suspend/resume cycle. So ENOENT is no error but
-		 * might happen in those cases.
+		 * might happen in those cases. ERANGE is observed when we get
+		 * an empty value (''), this happens when we acknowledge the
+		 * request by writing '\0' below.
 		 */
-		if (err != -ENOENT)
+		if (err != -ENOENT && err != -ERANGE)
 			pr_err("Error %d reading sysrq code in control/sysrq\n",
 			       err);
 		xenbus_transaction_end(xbt, 1);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #94 lore raw

PATCH 94/120 xen: fix GCC warning and remove duplicate EVTCHN_ROW/EVTCHN_COL usage

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

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

From: Josh Abraham <[email protected]>

[ Upstream commit 4dca864b59dd150a221730775e2f21f49779c135 ]

This patch removes duplicate macro useage in events_base.c.

It also fixes gcc warning:
variable ‘col’ set but not used [-Wunused-but-set-variable]

Signed-off-by Joshua Abraham <[email protected]>

Reviewed-by Juergen Gross <[email protected]>

Signed-off-by Boris Ostrovsky <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/xen/events/events_base.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/xen/events/events_base.c +1 -1

@@ -138,7 +138,7 @@ static int set_evtchn_to_irq(unsigned ev
 		clear_evtchn_to_irq_row(row);
 	}
 
-	evtchn_to_irq[EVTCHN_ROW(evtchn)][EVTCHN_COL(evtchn)] = irq;
+	evtchn_to_irq[row][col] = irq;
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #95 lore raw

PATCH 95/120 smb2: fix missing files in root share directory listing

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

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

From: Aurelien Aptel <[email protected]>

commit 0595751f267994c3c7027377058e4185b3a28e75 upstream.

When mounting a Windows share that is the root of a drive (eg. C$) the server does not return . and .. directory entries. This results in the smb2 code path erroneously skipping the 2 first entries.

Pseudo-code of the readdir() code path:

cifs_readdir(struct file, struct dir_context)
initiate_cifs_search <-- if no reponse cached yet
server->ops->query_dir_first

dir_emit_dots
dir_emit <-- adds "." and ".." if we're at pos=0

find_cifs_entry
initiate_cifs_search <-- if pos < start of current response
(restart search)
server->ops->query_dir_next <-- if pos > end of current response
(fetch next search res)

for(...) <-- loops over cur response entries
starting at pos
cifs_filldir <-- skip . and .., emit entry
cifs_fill_dirent
dir_emit
pos++

A) dir_emit_dots() always adds . & ..
and sets the current dir pos to 2 (0 and 1 are done).

Therefore we always want the index_to_find to be 2 regardless of if the response has . and ..

B) smb1 code initializes index_of_last_entry with a +2 offset

in cifssmb.c CIFSFindFirst():

		psrch_inf->index_of_last_entry = 2 /* skip . and .. */ +
			psrch_inf->entries_in_buffer;

Later in find_cifs_entry() we want to find the next dir entry at pos=2 as a result of (A)

	first_entry_in_buffer = cfile->srch_inf.index_of_last_entry -
					cfile->srch_inf.entries_in_buffer;

This var is the dir pos that the first entry in the buffer will have therefore it must be 2 in the first call.

If we don't offset index_of_last_entry by 2 (like in (B)), first_entry_in_buffer=0 but we were instructed to get pos=2 so this code in find_cifs_entry() skips the 2 first which is ok for non-root shares, as it skips . and .. from the response but is not ok for root shares where the 2 first are actual files

		pos_in_buf = index_to_find - first_entry_in_buffer;
                // pos_in_buf=2
		// we skip 2 first response entries :(
		for (i = 0; (i < (pos_in_buf)) && (cur_ent != NULL); i++) {
			/* go entry by entry figuring out which is first */
			cur_ent = nxt_dir_entry(cur_ent, end_of_smb,
						cfile->srch_inf.info_level);
		}

C) cifs_filldir() skips . and .. so we can safely ignore them for now.

Sample program:

int main(int argc, char **argv)

{
	const char *path = argc >= 2 ? argv[1] : ".";
	DIR *dh;
	struct dirent *de;

	printf("listing path <%s>\n", path);
	dh = opendir(path);
	if (!dh) {
		printf("opendir error %d\n", errno);
		return 1;
	}

	while (1) {
		de = readdir(dh);
		if (!de) {
			if (errno) {
				printf("readdir error %d\n", errno);
				return 1;
			}
			printf("end of listing\n");
			break;
		}
		printf("off=%lu <%s>\n", de->d_off, de->d_name);
	}

	return 0;
}

Before the fix with SMB1 on root shares:

<.> off=1
<..> off=2
<$Recycle.Bin> off=3
<bootmgr> off=4

and on non-root shares:

<.> off=1
<..> off=4 <-- after adding .., the offsets jumps to +2 because
<2536> off=5 we skipped . and .. from response buffer (C)
<411> off=6 but still incremented pos
<file> off=7
<fsx> off=8

Therefore the fix for smb2 is to mimic smb1 behaviour and offset the index_of_last_entry by 2.

Test results comparing smb1 and smb2 before/after the fix on root share, non-root shares and on large directories (ie. multi-response dir listing):

PRE FIX
=======
pre-1-root VS pre-2-root:
ERR pre-2-root is missing [bootmgr, $Recycle.Bin]
pre-1-nonroot VS pre-2-nonroot:
OK~ same files, same order, different offsets
pre-1-nonroot-large VS pre-2-nonroot-large:
OK~ same files, same order, different offsets

POST FIX
========
post-1-root VS post-2-root:
OK same files, same order, same offsets
post-1-nonroot VS post-2-nonroot:
OK same files, same order, same offsets
post-1-nonroot-large VS post-2-nonroot-large:
OK same files, same order, same offsets

REGRESSION?
===========
pre-1-root VS post-1-root:
OK same files, same order, same offsets
pre-1-nonroot VS post-1-nonroot:
OK same files, same order, same offsets

BugLink https://bugzilla.samba.org/show_bug.cgi?id=13107

Signed-off-by Aurelien Aptel <[email protected]>

Signed-off-by Paulo Alcantara <[email protected]>

Reviewed-by Ronnie Sahlberg <[email protected]>

CC Stable <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/cifs/smb2ops.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/cifs/smb2ops.c +1 -1

@@ -847,7 +847,7 @@ smb2_query_dir_first(const unsigned int
 	}
 
 	srch_inf->entries_in_buffer = 0;
-	srch_inf->index_of_last_entry = 0;
+	srch_inf->index_of_last_entry = 2;
 
 	rc = SMB2_query_directory(xid, tcon, fid->persistent_fid,
 				  fid->volatile_fid, 0, srch_inf);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #96 lore raw

PATCH 96/120 crypto: mxs-dcp - Fix wait logic on chan threads

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

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

From: Leonard Crestez <[email protected]>

commit d80771c08363ad7fbf0f56f5301e7ca65065c582 upstream.

When compiling with CONFIG_DEBUG_ATOMIC_SLEEP=y the mxs-dcp driver prints warnings such as:

WARNING: CPU: 0 PID: 120 at kernel/sched/core.c:7736 __might_sleep+0x98/0x9c
do not call blocking ops when !TASK_RUNNING; state=1 set at [<8081978c>] dcp_chan_thread_sha+0x3c/0x2ec

The problem is that blocking ops will manipulate current->state themselves so it is not allowed to call them between set_current_state(TASK_INTERRUPTIBLE) and schedule().

Fix this by converting the per-chan mutex to a spinlock (it only protects tiny list ops anyway) and rearranging the wait logic so that callbacks are called current->state as TASK_RUNNING. Those callbacks will indeed call blocking ops themselves so this is required.

Signed-off-by Leonard Crestez <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/crypto/mxs-dcp.c |   53 ++++++++++++++++++++++++++---------------------
 1 file changed, 30 insertions(+), 23 deletions(-)

drivers/crypto/mxs-dcp.c +30 ~~-23~~

@@ -63,7 +63,7 @@ struct dcp {
 	struct dcp_coherent_block	*coh;
 
 	struct completion		completion[DCP_MAX_CHANS];
-	struct mutex			mutex[DCP_MAX_CHANS];
+	spinlock_t			lock[DCP_MAX_CHANS];
 	struct task_struct		*thread[DCP_MAX_CHANS];
 	struct crypto_queue		queue[DCP_MAX_CHANS];
 };

@@ -349,13 +349,20 @@ static int dcp_chan_thread_aes(void *dat
 
 	int ret;
 
-	do {
-		__set_current_state(TASK_INTERRUPTIBLE);
+	while (!kthread_should_stop()) {
+		set_current_state(TASK_INTERRUPTIBLE);
 
-		mutex_lock(&sdcp->mutex[chan]);
+		spin_lock(&sdcp->lock[chan]);
 		backlog = crypto_get_backlog(&sdcp->queue[chan]);
 		arq = crypto_dequeue_request(&sdcp->queue[chan]);
-		mutex_unlock(&sdcp->mutex[chan]);
+		spin_unlock(&sdcp->lock[chan]);
+
+		if (!backlog && !arq) {
+			schedule();
+			continue;
+		}
+
+		set_current_state(TASK_RUNNING);
 
 		if (backlog)
 			backlog->complete(backlog, -EINPROGRESS);

@@ -363,11 +370,8 @@ static int dcp_chan_thread_aes(void *dat
 		if (arq) {
 			ret = mxs_dcp_aes_block_crypt(arq);
 			arq->complete(arq, ret);
-			continue;
 		}
-
-		schedule();
-	} while (!kthread_should_stop());
+	}
 
 	return 0;
 }

@@ -407,9 +411,9 @@ static int mxs_dcp_aes_enqueue(struct ab
 	rctx->ecb = ecb;
 	actx->chan = DCP_CHAN_CRYPTO;
 
-	mutex_lock(&sdcp->mutex[actx->chan]);
+	spin_lock(&sdcp->lock[actx->chan]);
 	ret = crypto_enqueue_request(&sdcp->queue[actx->chan], &req->base);
-	mutex_unlock(&sdcp->mutex[actx->chan]);
+	spin_unlock(&sdcp->lock[actx->chan]);
 
 	wake_up_process(sdcp->thread[actx->chan]);

@@ -645,13 +649,20 @@ static int dcp_chan_thread_sha(void *dat
 	struct ahash_request *req;
 	int ret, fini;
 
-	do {
-		__set_current_state(TASK_INTERRUPTIBLE);
+	while (!kthread_should_stop()) {
+		set_current_state(TASK_INTERRUPTIBLE);
 
-		mutex_lock(&sdcp->mutex[chan]);
+		spin_lock(&sdcp->lock[chan]);
 		backlog = crypto_get_backlog(&sdcp->queue[chan]);
 		arq = crypto_dequeue_request(&sdcp->queue[chan]);
-		mutex_unlock(&sdcp->mutex[chan]);
+		spin_unlock(&sdcp->lock[chan]);
+
+		if (!backlog && !arq) {
+			schedule();
+			continue;
+		}
+
+		set_current_state(TASK_RUNNING);
 
 		if (backlog)
 			backlog->complete(backlog, -EINPROGRESS);

@@ -663,12 +674,8 @@ static int dcp_chan_thread_sha(void *dat
 			ret = dcp_sha_req_to_buf(arq);
 			fini = rctx->fini;
 			arq->complete(arq, ret);
-			if (!fini)
-				continue;
 		}
-
-		schedule();
-	} while (!kthread_should_stop());
+	}
 
 	return 0;
 }

@@ -726,9 +733,9 @@ static int dcp_sha_update_fx(struct ahas
 		rctx->init = 1;
 	}
 
-	mutex_lock(&sdcp->mutex[actx->chan]);
+	spin_lock(&sdcp->lock[actx->chan]);
 	ret = crypto_enqueue_request(&sdcp->queue[actx->chan], &req->base);
-	mutex_unlock(&sdcp->mutex[actx->chan]);
+	spin_unlock(&sdcp->lock[actx->chan]);
 
 	wake_up_process(sdcp->thread[actx->chan]);
 	mutex_unlock(&actx->mutex);

@@ -984,7 +991,7 @@ static int mxs_dcp_probe(struct platform
 	platform_set_drvdata(pdev, sdcp);
 
 	for (i = 0; i < DCP_MAX_CHANS; i++) {
-		mutex_init(&sdcp->mutex[i]);
+		spin_lock_init(&sdcp->lock[i]);
 		init_completion(&sdcp->completion[i]);
 		crypto_init_queue(&sdcp->queue[i], 50);
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #97 lore raw

PATCH 97/120 ocfs2: fix locking for res->tracking and dlm->tracking_list

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

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

From: Ashish Samant <[email protected]>

commit cbe355f57c8074bc4f452e5b6e35509044c6fa23 upstream.

In dlm_init_lockres() we access and modify res->tracking and dlm->tracking_list without holding dlm->track_lock. This can cause list corruptions and can end up in kernel panic.

Fix this by locking res->tracking and dlm->tracking_list with dlm->track_lock instead of dlm->spinlock.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ashish Samant <[email protected]>

Reviewed-by Changwei Ge <[email protected]>

Acked-by Joseph Qi <[email protected]>

Acked-by Jun Piao <[email protected]>

Cc Mark Fasheh <[email protected]>

Cc Joel Becker <[email protected]>

Cc Junxiao Bi <[email protected]>

Cc Changwei Ge <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ocfs2/dlm/dlmmaster.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

fs/ocfs2/dlm/dlmmaster.c +2 -2

@@ -599,9 +599,9 @@ static void dlm_init_lockres(struct dlm_
 
 	res->last_used = 0;
 
-	spin_lock(&dlm->spinlock);
+	spin_lock(&dlm->track_lock);
 	list_add_tail(&res->tracking, &dlm->tracking_list);
-	spin_unlock(&dlm->spinlock);
+	spin_unlock(&dlm->track_lock);
 
 	memset(res->lvb, 0, DLM_LVB_LEN);
 	memset(res->refmap, 0, sizeof(res->refmap));

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #98 lore raw

PATCH 98/120 dm thin metadata: fix __udivdi3 undefined on 32-bit

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

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

From: Mike Snitzer <[email protected]>

commit 013ad043906b2befd4a9bfb06219ed9fedd92716 upstream.

sector_div() is only viable for use with sector_t. dm_block_t is typedef'd to uint64_t -- so use div_u64() instead.

Fixes 3ab918281 ("dm thin metadata: try to avoid ever aborting transactions")

Signed-off-by Mike Snitzer <[email protected]>

Cc Sudip Mukherjee <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/md/dm-thin-metadata.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

drivers/md/dm-thin-metadata.c +2 -4

@@ -840,10 +840,8 @@ static void __set_metadata_reserve(struc
 	if (r) {
 		DMERR("could not get size of metadata device");
 		pmd->metadata_reserve = max_blocks;
-	} else {
-		sector_div(total, 10);
-		pmd->metadata_reserve = min(max_blocks, total);
-	}
+	} else
+		pmd->metadata_reserve = min(max_blocks, div_u64(total, 10));
 }
 
 struct dm_pool_metadata *dm_pool_metadata_open(struct block_device *bdev,

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #99 lore raw

PATCH 99/120 Make file credentials available to the seqfile interfaces

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

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

From: Linus Torvalds <[email protected]>

commit 34dbbcdbf63360661ff7bda6c5f52f99ac515f92 upstream.

A lot of seqfile users seem to be using things like %pK that uses the credentials of the current process, but that is actually completely wrong for filesystem interfaces.

The unix semantics for permission checking files is to check permissions at _open_ time, not at read or write time, and that is not just a small
detail: passing off stdin/stdout/stderr to a suid application and making the actual IO happen in privileged context is a classic exploit technique.

So if we want to be able to look at permissions at read time, we need to use the file open credentials, not the current ones. Normal file accesses can just use "f_cred" (or any of the helper functions that do that, like file_ns_capable()), but the seqfile interfaces do not have any such options.

It turns out that seq_file _does_ save away the user_ns information of the file, though. Since user_ns is just part of the full credential information, replace that special case with saving off the cred pointer instead, and suddenly seq_file has all the permission information it needs.

Cc Jann Horn <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/seq_file.c            |    7 ++++---
 include/linux/seq_file.h |   13 ++++---------
 2 files changed, 8 insertions(+), 12 deletions(-)

fs/seq_file.c +4 -3

@@ -69,9 +69,10 @@ int seq_open(struct file *file, const st
 	memset(p, 0, sizeof(*p));
 	mutex_init(&p->lock);
 	p->op = op;
-#ifdef CONFIG_USER_NS
-	p->user_ns = file->f_cred->user_ns;
-#endif
+
+	// No refcounting: the lifetime of 'p' is constrained
+	// to the lifetime of the file.
+	p->file = file;
 
 	/*
 	 * Wrappers around seq_open(e.g. swaps_open) need to be

include/linux/seq_file.h +4 -9

@@ -7,13 +7,10 @@
 #include <linux/mutex.h>
 #include <linux/cpumask.h>
 #include <linux/nodemask.h>
+#include <linux/fs.h>
+#include <linux/cred.h>
 
 struct seq_operations;
-struct file;
-struct path;
-struct inode;
-struct dentry;
-struct user_namespace;
 
 struct seq_file {
 	char *buf;

@@ -27,9 +24,7 @@ struct seq_file {
 	struct mutex lock;
 	const struct seq_operations *op;
 	int poll_event;
-#ifdef CONFIG_USER_NS
-	struct user_namespace *user_ns;
-#endif
+	const struct file *file;
 	void *private;
 };

@@ -151,7 +146,7 @@ int seq_put_decimal_ll(struct seq_file *
 static inline struct user_namespace *seq_user_ns(struct seq_file *seq)
 {
 #ifdef CONFIG_USER_NS
-	return seq->user_ns;
+	return seq->file->f_cred->user_ns;
 #else
 	extern struct user_namespace init_user_ns;
 	return &init_user_ns;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #100 lore raw

PATCH 100/120 proc: restrict kernel stack dumps to root

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

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

From: Jann Horn <[email protected]>

commit f8a00cef17206ecd1b30d3d9f99e10d9fa707aa7 upstream.

Currently, you can use /proc/self/task/*/stack to cause a stack walk on a task you control while it is running on another CPU. That means that the stack can change under the stack walker. The stack walker does have guards against going completely off the rails and into random kernel memory, but it can interpret random data from your kernel stack as instruction pointers and stack pointers. This can cause exposure of kernel stack contents to userspace.

Restrict the ability to inspect kernel stacks of arbitrary tasks to root in order to prevent a local attacker from exploiting racy stack unwinding to leak kernel task stack contents. See the added comment for a longer rationale.

There don't seem to be any users of this userspace API that can't gracefully bail out if reading from the file fails. Therefore, I believe that this change is unlikely to break things. In the case that this patch does end up needing a revert, the next-best solution might be to fake a single-entry stack based on wchan.

Link http://lkml.kernel.org/r/[email protected] open here

Fixes 2ec220e27f50 ("proc: add /proc/*/stack")

Signed-off-by Jann Horn <[email protected]>

Acked-by Kees Cook <[email protected]>

Cc Alexey Dobriyan <[email protected]>

Cc Ken Chen <[email protected]>

Cc Will Deacon <[email protected]>

Cc Laura Abbott <[email protected]>

Cc Andy Lutomirski <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Josh Poimboeuf <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc "H . Peter Anvin" <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/proc/base.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

fs/proc/base.c +14 -0

@@ -279,6 +279,20 @@ static int proc_pid_stack(struct seq_fil
 	int err;
 	int i;
 
+	/*
+	 * The ability to racily run the kernel stack unwinder on a running task
+	 * and then observe the unwinder output is scary; while it is useful for
+	 * debugging kernel issues, it can also allow an attacker to leak kernel
+	 * stack contents.
+	 * Doing this in a manner that is at least safe from races would require
+	 * some work to ensure that the remote task can not be scheduled; and
+	 * even then, this would still expose the unwinder as local attack
+	 * surface.
+	 * Therefore, this interface is restricted to root.
+	 */
+	if (!file_ns_capable(m->file, &init_user_ns, CAP_SYS_ADMIN))
+		return -EACCES;
+
 	entries = kmalloc(MAX_STACK_TRACE_DEPTH * sizeof(*entries), GFP_KERNEL);
 	if (!entries)
 		return -ENOMEM;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #101 lore raw

PATCH 101/120 fbdev/omapfb: fix omapfb_memory_read infoleak

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

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

From: Tomi Valkeinen <[email protected]>

commit 1bafcbf59fed92af58955024452f45430d3898c5 upstream.

OMAPFB_MEMORY_READ ioctl reads pixels from the LCD's memory and copies them to a userspace buffer. The code has two issues:

- The user provided width and height could be large enough to overflow the calculations
- The copy_to_user() can copy uninitialized memory to the userspace, which might contain sensitive kernel information.

Fix these by limiting the width & height parameters, and only copying the amount of data that we actually received from the LCD.

Signed-off-by Tomi Valkeinen <[email protected]>

Reported-by Jann Horn <[email protected]>

Cc Will Deacon <[email protected]>

Cc Jann Horn <[email protected]>

Cc Tony Lindgren <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/video/fbdev/omap2/omapfb/omapfb-ioctl.c +4 -1

@@ -493,6 +493,9 @@ static int omapfb_memory_read(struct fb_
 	if (!access_ok(VERIFY_WRITE, mr->buffer, mr->buffer_size))
 		return -EFAULT;
 
+	if (mr->w > 4096 || mr->h > 4096)
+		return -EINVAL;
+
 	if (mr->w * mr->h * 3 > mr->buffer_size)
 		return -EINVAL;

@@ -506,7 +509,7 @@ static int omapfb_memory_read(struct fb_
 			mr->x, mr->y, mr->w, mr->h);
 
 	if (r > 0) {
-		if (copy_to_user(mr->buffer, buf, mr->buffer_size))
+		if (copy_to_user(mr->buffer, buf, r))
 			r = -EFAULT;
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #102 lore raw

PATCH 102/120 x86/vdso: Fix asm constraints on vDSO syscall fallbacks

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

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

From: Andy Lutomirski <[email protected]>

commit 715bd9d12f84d8f5cc8ad21d888f9bc304a8eb0b upstream.

The syscall fallbacks in the vDSO have incorrect asm constraints. They are not marked as writing to their outputs -- instead, they are marked as clobbering "memory", which is useless. In particular, gcc is smart enough to know that the timespec parameter hasn't escaped, so a memory clobber doesn't clobber it. And passing a pointer as an asm *input* does not tell gcc that the pointed-to value is changed.

Add in the fact that the asm instructions weren't volatile, and gcc was free to omit them entirely unless their sole output (the return value) is used. Which it is (phew!), but that stops happening with some upcoming patches.

As a trivial example, the following code:

void test_fallback(struct timespec *ts)

{
	vdso_fallback_gettime(CLOCK_MONOTONIC, ts);
}

compiles to:

00000000000000c0 <test_fallback>:
c0: c3 retq

To add insult to injury, the RCX and R11 clobbers on 64-bit builds were missing.

The "memory" clobber is also unnecessary -- no ordering with respect to other memory operations is needed, but that's going to be fixed in a separate not-for-stable patch.

Fixes 2aae950b21e4 ("x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu")

Signed-off-by Andy Lutomirski <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Link https://lkml.kernel.org/r/2c0231690551989d2fafa60ed0e7b5cc8b403908.1538422295.git.luto@kernel.org open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/vdso/vclock_gettime.c |   18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

arch/x86/vdso/vclock_gettime.c +10 -8

@@ -46,8 +46,9 @@ static notrace cycle_t vread_hpet(void)
 notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
 {
 	long ret;
-	asm("syscall" : "=a" (ret) :
-	    "0" (__NR_clock_gettime), "D" (clock), "S" (ts) : "memory");
+	asm ("syscall" : "=a" (ret), "=m" (*ts) :
+	     "0" (__NR_clock_gettime), "D" (clock), "S" (ts) :
+	     "memory", "rcx", "r11");
 	return ret;
 }

@@ -55,8 +56,9 @@ notrace static long vdso_fallback_gtod(s
 {
 	long ret;
 
-	asm("syscall" : "=a" (ret) :
-	    "0" (__NR_gettimeofday), "D" (tv), "S" (tz) : "memory");
+	asm ("syscall" : "=a" (ret), "=m" (*tv), "=m" (*tz) :
+	     "0" (__NR_gettimeofday), "D" (tv), "S" (tz) :
+	     "memory", "rcx", "r11");
 	return ret;
 }

@@ -136,12 +138,12 @@ notrace static long vdso_fallback_gettim
 {
 	long ret;
 
-	asm(
+	asm (
 		"mov %%ebx, %%edx \n"
 		"mov %2, %%ebx \n"
 		"call __kernel_vsyscall \n"
 		"mov %%edx, %%ebx \n"
-		: "=a" (ret)
+		: "=a" (ret), "=m" (*ts)
 		: "0" (__NR_clock_gettime), "g" (clock), "c" (ts)
 		: "memory", "edx");
 	return ret;

@@ -151,12 +153,12 @@ notrace static long vdso_fallback_gtod(s
 {
 	long ret;
 
-	asm(
+	asm (
 		"mov %%ebx, %%edx \n"
 		"mov %2, %%ebx \n"
 		"call __kernel_vsyscall \n"
 		"mov %%edx, %%ebx \n"
-		: "=a" (ret)
+		: "=a" (ret), "=m" (*tv), "=m" (*tz)
 		: "0" (__NR_gettimeofday), "g" (tv), "c" (tz)
 		: "memory", "edx");
 	return ret;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #103 lore raw

PATCH 103/120 x86/vdso: Fix vDSO syscall fallback asm constraint regression

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

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

From: Andy Lutomirski <[email protected]>

commit 02e425668f5c9deb42787d10001a3b605993ad15 upstream.

When I added the missing memory outputs, I failed to update the index of the first argument (ebx) on 32-bit builds, which broke the fallbacks. Somehow I must have screwed up my testing or gotten lucky.

Add another test to cover gettimeofday() as well.

Signed-off-by Andy Lutomirski <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Thomas Gleixner <[email protected]>

Link http://lkml.kernel.org/r/21bd45ab04b6d838278fa5bebfa9163eceffa13c.1538608971.git.luto@kernel.org open here

Fixes 715bd9d12f84 ("x86/vdso: Fix asm constraints on vDSO syscall fallbacks")

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 arch/x86/vdso/vclock_gettime.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/x86/vdso/vclock_gettime.c +4 -4

@@ -140,11 +140,11 @@ notrace static long vdso_fallback_gettim
 
 	asm (
 		"mov %%ebx, %%edx \n"
-		"mov %2, %%ebx \n"
+		"mov %[clock], %%ebx \n"
 		"call __kernel_vsyscall \n"
 		"mov %%edx, %%ebx \n"
 		: "=a" (ret), "=m" (*ts)
-		: "0" (__NR_clock_gettime), "g" (clock), "c" (ts)
+		: "0" (__NR_clock_gettime), [clock] "g" (clock), "c" (ts)
 		: "memory", "edx");
 	return ret;
 }

@@ -155,11 +155,11 @@ notrace static long vdso_fallback_gtod(s
 
 	asm (
 		"mov %%ebx, %%edx \n"
-		"mov %2, %%ebx \n"
+		"mov %[tv], %%ebx \n"
 		"call __kernel_vsyscall \n"
 		"mov %%edx, %%ebx \n"
 		: "=a" (ret), "=m" (*tv), "=m" (*tz)
-		: "0" (__NR_gettimeofday), "g" (tv), "c" (tz)
+		: "0" (__NR_gettimeofday), [tv] "g" (tv), "c" (tz)
 		: "memory", "edx");
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #104 lore raw

PATCH 104/120 PCI: Reprogram bridge prefetch registers on resume

Link https://bugzilla.kernel.org/show_bug.cgi?id=201069

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

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

From: Daniel Drake <[email protected]>

commit 083874549fdfefa629dfa752785e20427dde1511 upstream.

On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3 suspend/resume. The affected products include multiple generations of NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such as:

fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04

        [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]

DRM: failed to idle channel 0 [DRM]

Similarly, the NVIDIA proprietary driver also fails after resume (black screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for diagnosis, and their response indicated that it's a problem with the parent PCI bridge (on the Intel SoC), not the GPU.

Runtime suspend/resume works fine, only S3 suspend is affected.

We found a workaround: on resume, rewrite the Intel PCI bridge 'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the cases that I checked, this register has value 0 and we just have to rewrite that value.

Linux already saves and restores PCI config space during suspend/resume, but this register was being skipped because upon resume, it already has value 0 (the correct, pre-suspend value).

Intel appear to have previously acknowledged this behaviour and the requirement to rewrite this register:
https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23

Based on that, rewrite the prefetch register values even when that appears unnecessary.

We have confirmed this solution on all the affected models we have in-hands (X542UQ, UX533FD, X530UN, V272UN).

Additionally, this solves an issue where r8169 MSI-X interrupts were broken after S3 suspend/resume on ASUS X441UAR. This issue was recently worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop that we had not yet patched. I suspect it will also fix the issue that was worked around in commit 7c53a722459c ("r8169: don't use MSI-X on RTL8168g").

Thomas Martitz reports that this change also solves an issue where the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3 suspend/resume.

Signed-off-by Daniel Drake <[email protected]>

Signed-off-by Bjorn Helgaas <[email protected]>

Reviewed-by Rafael J. Wysocki <[email protected]>

Reviewed-by Peter Wu <[email protected]>

CC [email protected]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/pci/pci.c |   27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

drivers/pci/pci.c +19 -8

@@ -1023,12 +1023,12 @@ int pci_save_state(struct pci_dev *dev)
 EXPORT_SYMBOL(pci_save_state);
 
 static void pci_restore_config_dword(struct pci_dev *pdev, int offset,
-				     u32 saved_val, int retry)
+				     u32 saved_val, int retry, bool force)
 {
 	u32 val;
 
 	pci_read_config_dword(pdev, offset, &val);
-	if (val == saved_val)
+	if (!force && val == saved_val)
 		return;
 
 	for (;;) {

@@ -1047,25 +1047,36 @@ static void pci_restore_config_dword(str
 }
 
 static void pci_restore_config_space_range(struct pci_dev *pdev,
-					   int start, int end, int retry)
+					   int start, int end, int retry,
+					   bool force)
 {
 	int index;
 
 	for (index = end; index >= start; index--)
 		pci_restore_config_dword(pdev, 4 * index,
 					 pdev->saved_config_space[index],
-					 retry);
+					 retry, force);
 }
 
 static void pci_restore_config_space(struct pci_dev *pdev)
 {
 	if (pdev->hdr_type == PCI_HEADER_TYPE_NORMAL) {
-		pci_restore_config_space_range(pdev, 10, 15, 0);
+		pci_restore_config_space_range(pdev, 10, 15, 0, false);
 		/* Restore BARs before the command register. */
-		pci_restore_config_space_range(pdev, 4, 9, 10);
-		pci_restore_config_space_range(pdev, 0, 3, 0);
+		pci_restore_config_space_range(pdev, 4, 9, 10, false);
+		pci_restore_config_space_range(pdev, 0, 3, 0, false);
+	} else if (pdev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+		pci_restore_config_space_range(pdev, 12, 15, 0, false);
+
+		/*
+		 * Force rewriting of prefetch registers to avoid S3 resume
+		 * issues on Intel PCI bridges that occur when these
+		 * registers are not explicitly written.
+		 */
+		pci_restore_config_space_range(pdev, 9, 11, 0, true);
+		pci_restore_config_space_range(pdev, 0, 8, 0, false);
 	} else {
-		pci_restore_config_space_range(pdev, 0, 15, 0);
+		pci_restore_config_space_range(pdev, 0, 15, 0, false);
 	}
 }

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #105 lore raw

PATCH 105/120 mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys

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

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

From: Felix Fietkau <[email protected]>

commit 211710ca74adf790b46ab3867fcce8047b573cd1 upstream.

key->sta is only valid after ieee80211_key_link, which is called later in this function. Because of that, the IEEE80211_KEY_FLAG_RX_MGMT is never set when management frame protection is enabled.

Fixes e548c49e6dc6b ("mac80211: add key flag for management keys")

Signed-off-by Felix Fietkau <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 net/mac80211/cfg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/mac80211/cfg.c +1 -1

@@ -210,7 +210,7 @@ static int ieee80211_add_key(struct wiph
 	case NL80211_IFTYPE_AP:
 	case NL80211_IFTYPE_AP_VLAN:
 		/* Keys without a station are used for TX only */
-		if (key->sta && test_sta_flag(key->sta, WLAN_STA_MFP))
+		if (sta && test_sta_flag(sta, WLAN_STA_MFP))
 			key->conf.flags |= IEEE80211_KEY_FLAG_RX_MGMT;
 		break;
 	case NL80211_IFTYPE_ADHOC:

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #106 lore raw

PATCH 106/120 PM / core: Clear the direct_complete flag on errors

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

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

From: Rafael J. Wysocki <[email protected]>

commit 69e445ab8b66a9f30519842ef18be555d3ee9b51 upstream.

If __device_suspend() runs asynchronously (in which case the device passed to it is in dpm_suspended_list at that point) and it returns early on an error or pending wakeup, and the power.direct_complete flag has been set for the device already, the subsequent device_resume() will be confused by that and it will call pm_runtime_enable() incorrectly, as runtime PM has not been disabled for the device by __device_suspend().

To avoid that, clear power.direct_complete if __device_suspend() is not going to disable runtime PM for the device before returning.

Fixes aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily)

Reported-by Al Cooper <[email protected]>

Tested-by Al Cooper <[email protected]>

Reviewed-by Ulf Hansson <[email protected]>

Cc 3.16+ <[email protected]> # 3.16+

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/base/power/main.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/base/power/main.c +4 -1

@@ -1341,8 +1341,10 @@ static int __device_suspend(struct devic
 
 	dpm_wait_for_children(dev, async);
 
-	if (async_error)
+	if (async_error) {
+		dev->power.direct_complete = false;
 		goto Complete;
+	}
 
 	/*
 	 * If a device configured to wake up the system from sleep states

@@ -1354,6 +1356,7 @@ static int __device_suspend(struct devic
 		pm_wakeup_event(dev, 0);
 
 	if (pm_wakeup_pending()) {
+		dev->power.direct_complete = false;
 		async_error = -EBUSY;
 		goto Complete;
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #107 lore raw

PATCH 107/120 USB: serial: simple: add Motorola Tetra MTP6550 id

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

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

From: Johan Hovold <[email protected]>

commit f5fad711c06e652f90f581fc7c2caee327c33d31 upstream.

Add device-id for the Motorola Tetra radio MTP6550.

Bus 001 Device 004: ID 0cad:9012 Motorola CGISS
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00

  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0cad Motorola CGISS
  idProduct          0x9012
  bcdDevice           24.16
  iManufacturer           1 Motorola Solutions, Inc.
  iProduct                2 TETRA PEI interface
  iSerial                 0
  bNumConfigurations      1

Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 55
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 3 Generic Serial config
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00

  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0

bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)

Reported-by Hans Hult <[email protected]>

Cc stable <[email protected]>

Signed-off-by Johan Hovold <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/usb/serial/usb-serial-simple.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/usb/serial/usb-serial-simple.c +2 -1

@@ -74,7 +74,8 @@ DEVICE(moto_modem, MOTO_IDS);
 
 /* Motorola Tetra driver */
 #define MOTOROLA_TETRA_IDS()			\
-	{ USB_DEVICE(0x0cad, 0x9011) }	/* Motorola Solutions TETRA PEI */
+	{ USB_DEVICE(0x0cad, 0x9011) },	/* Motorola Solutions TETRA PEI */ \
+	{ USB_DEVICE(0x0cad, 0x9012) }	/* MTP6550 */
 DEVICE(motorola_tetra, MOTOROLA_TETRA_IDS);
 
 /* Novatel Wireless GPS driver */

Greg Kroah-Hartman

author maintainer

2018-10-11 15:34 UTC #108 lore raw

PATCH 108/120 ext4: only look at the bg_flags field if it is valid

https://bugzilla.kernel.org/show_bug.cgi?id=199403

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

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

From: Theodore Ts'o <[email protected]>

commit 8844618d8aa7a9973e7b527d038a2a589665002c upstream.

The bg_flags field in the block group descripts is only valid if the uninit_bg or metadata_csum feature is enabled. We were not consistently looking at this field; fix this.

Also block group #0 must never have uninitialized allocation bitmaps, or need to be zeroed, since that's where the root inode, and other special inodes are set up. Check for these conditions and mark the file system as corrupted if they are detected.

This addresses CVE-2018-10876.

[bwh: Backported to 3.16:
- ext4_read_block_bitmap_nowait() and ext4_read_inode_bitmap() return a pointer (NULL on error) instead of an error code
- Open-code sb_rdonly()
- Adjust context]

[[email protected]: forward-port to 3.18: adjust context]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/balloc.c  |   11 ++++++++++-
 fs/ext4/ialloc.c  |   14 ++++++++++++--
 fs/ext4/mballoc.c |    6 ++++--
 fs/ext4/super.c   |   11 ++++++++++-
 4 files changed, 36 insertions(+), 6 deletions(-)

fs/ext4/balloc.c +10 -1

@@ -451,9 +451,18 @@ ext4_read_block_bitmap_nowait(struct sup
 		goto verify;
 	}
 	ext4_lock_group(sb, block_group);
-	if (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
+	if (ext4_has_group_desc_csum(sb) &&
+	    (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT))) {
 		int err;
 
+		if (block_group == 0) {
+			ext4_unlock_group(sb, block_group);
+			unlock_buffer(bh);
+			ext4_error(sb, "Block bitmap for bg 0 marked "
+				   "uninitialized");
+			put_bh(bh);
+			return NULL;
+		}
 		err = ext4_init_block_bitmap(sb, bh, block_group, desc);
 		set_bitmap_uptodate(bh);
 		set_buffer_uptodate(bh);

fs/ext4/ialloc.c +12 -2

@@ -117,7 +117,16 @@ ext4_read_inode_bitmap(struct super_bloc
 	}
 
 	ext4_lock_group(sb, block_group);
-	if (desc->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT)) {
+	if (ext4_has_group_desc_csum(sb) &&
+	    (desc->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT))) {
+		if (block_group == 0) {
+			ext4_unlock_group(sb, block_group);
+			unlock_buffer(bh);
+			ext4_error(sb, "Inode bitmap for bg 0 marked "
+				   "uninitialized");
+			put_bh(bh);
+			return NULL;
+		}
 		memset(bh->b_data, 0, (EXT4_INODES_PER_GROUP(sb) + 7) / 8);
 		ext4_mark_bitmap_end(EXT4_INODES_PER_GROUP(sb),
 				     sb->s_blocksize * 8, bh->b_data);

@@ -873,7 +882,8 @@ got:
 
 		/* recheck and clear flag under lock if we still need to */
 		ext4_lock_group(sb, group);
-		if (gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
+		if (ext4_has_group_desc_csum(sb) &&
+		    (gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT))) {
 			gdp->bg_flags &= cpu_to_le16(~EXT4_BG_BLOCK_UNINIT);
 			ext4_free_group_clusters_set(sb, gdp,
 				ext4_free_clusters_after_init(sb, group, gdp));

fs/ext4/mballoc.c +4 -2

@@ -2415,7 +2415,8 @@ int ext4_mb_add_groupinfo(struct super_b
 	 * initialize bb_free to be able to skip
 	 * empty groups without initialization
 	 */
-	if (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
+	if (ext4_has_group_desc_csum(sb) &&
+	    (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT))) {
 		meta_group_info[i]->bb_free =
 			ext4_free_clusters_after_init(sb, group, desc);
 	} else {

@@ -2942,7 +2943,8 @@ ext4_mb_mark_diskspace_used(struct ext4_
 #endif
 	ext4_set_bits(bitmap_bh->b_data, ac->ac_b_ex.fe_start,
 		      ac->ac_b_ex.fe_len);
-	if (gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
+	if (ext4_has_group_desc_csum(sb) &&
+	    (gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT))) {
 		gdp->bg_flags &= cpu_to_le16(~EXT4_BG_BLOCK_UNINIT);
 		ext4_free_group_clusters_set(sb, gdp,
 					     ext4_free_clusters_after_init(sb,

fs/ext4/super.c +10 -1

@@ -3132,13 +3132,22 @@ static ext4_group_t ext4_has_uninit_itab
 	ext4_group_t group, ngroups = EXT4_SB(sb)->s_groups_count;
 	struct ext4_group_desc *gdp = NULL;
 
+	if (!ext4_has_group_desc_csum(sb))
+		return ngroups;
+
 	for (group = 0; group < ngroups; group++) {
 		gdp = ext4_get_group_desc(sb, group, NULL);
 		if (!gdp)
 			continue;
 
-		if (!(gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_ZEROED)))
+		if (gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_ZEROED))
+			continue;
+		if (group != 0)
 			break;
+		ext4_error(sb, "Inode table for bg 0 marked as "
+			   "needing zeroing");
+		if (sb->s_flags & MS_RDONLY)
+			return ngroups;
 	}
 
 	return group;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #109 lore raw

PATCH 109/120 ext4: fix check to prevent initializing reserved inodes

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

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

From: Theodore Ts'o <[email protected]>

commit 5012284700775a4e6e3fbe7eac4c543c4874b559 upstream.

Commit 8844618d8aa7: "ext4: only look at the bg_flags field if it is valid" will complain if block group zero does not have the EXT4_BG_INODE_ZEROED flag set. Unfortunately, this is not correct, since a freshly created file system has this flag cleared. It gets almost immediately after the file system is mounted read-write --- but the following somewhat unlikely sequence will end up triggering a false positive report of a corrupted file system:

mkfs.ext4 /dev/vdc
mount -o ro /dev/vdc /vdc
mount -o remount,rw /dev/vdc

Instead, when initializing the inode table for block group zero, test to make sure that itable_unused count is not too large, since that is the case that will result in some or all of the reserved inodes getting cleared.

This fixes the failures reported by Eric Whiteney when running generic/230 and generic/231 in the the nojournal test case.

Fixes 8844618d8aa7 ("ext4: only look at the bg_flags field if it is valid")

Reported-by Eric Whitney <[email protected]>

[bwh: Backported to 3.16: adjust context]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/ialloc.c |    5 ++++-
 fs/ext4/super.c  |    8 +-------
 2 files changed, 5 insertions(+), 8 deletions(-)

fs/ext4/ialloc.c +4 -1

@@ -1253,7 +1253,10 @@ int ext4_init_inode_table(struct super_b
 			    ext4_itable_unused_count(sb, gdp)),
 			    sbi->s_inodes_per_block);
 
-	if ((used_blks < 0) || (used_blks > sbi->s_itb_per_group)) {
+	if ((used_blks < 0) || (used_blks > sbi->s_itb_per_group) ||
+	    ((group == 0) && ((EXT4_INODES_PER_GROUP(sb) -
+			       ext4_itable_unused_count(sb, gdp)) <
+			      EXT4_FIRST_INO(sb)))) {
 		ext4_error(sb, "Something is wrong with group %u: "
 			   "used itable blocks: %d; "
 			   "itable unused count: %u",

fs/ext4/super.c +1 -7

@@ -3140,14 +3140,8 @@ static ext4_group_t ext4_has_uninit_itab
 		if (!gdp)
 			continue;
 
-		if (gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_ZEROED))
-			continue;
-		if (group != 0)
+		if (!(gdp->bg_flags & cpu_to_le16(EXT4_BG_INODE_ZEROED)))
 			break;
-		ext4_error(sb, "Inode table for bg 0 marked as "
-			   "needing zeroing");
-		if (sb->s_flags & MS_RDONLY)
-			return ngroups;
 	}
 
 	return group;

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #110 lore raw

PATCH 110/120 ext4: always check block group bounds in ext4_init_block_bitmap()

https://bugzilla.kernel.org/show_bug.cgi?id=199865

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

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

From: Theodore Ts'o <[email protected]>

commit 819b23f1c501b17b9694325471789e6b5cc2d0d2 upstream.

Regardless of whether the flex_bg feature is set, we should always check to make sure the bits we are setting in the block bitmap are within the block group bounds.

[bwh: Backported to 3.16: adjust context]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/balloc.c |   10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

fs/ext4/balloc.c +3 -7

@@ -184,7 +184,6 @@ static int ext4_init_block_bitmap(struct
 	unsigned int bit, bit_max;
 	struct ext4_sb_info *sbi = EXT4_SB(sb);
 	ext4_fsblk_t start, tmp;
-	int flex_bg = 0;
 	struct ext4_group_info *grp;
 
 	J_ASSERT_BH(bh, buffer_locked(bh));

@@ -217,22 +216,19 @@ static int ext4_init_block_bitmap(struct
 
 	start = ext4_group_first_block_no(sb, block_group);
 
-	if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_FLEX_BG))
-		flex_bg = 1;
-
 	/* Set bits for block and inode bitmaps, and inode table */
 	tmp = ext4_block_bitmap(sb, gdp);
-	if (!flex_bg || ext4_block_in_group(sb, tmp, block_group))
+	if (ext4_block_in_group(sb, tmp, block_group))
 		ext4_set_bit(EXT4_B2C(sbi, tmp - start), bh->b_data);
 
 	tmp = ext4_inode_bitmap(sb, gdp);
-	if (!flex_bg || ext4_block_in_group(sb, tmp, block_group))
+	if (ext4_block_in_group(sb, tmp, block_group))
 		ext4_set_bit(EXT4_B2C(sbi, tmp - start), bh->b_data);
 
 	tmp = ext4_inode_table(sb, gdp);
 	for (; tmp < ext4_inode_table(sb, gdp) +
 		     sbi->s_itb_per_group; tmp++) {
-		if (!flex_bg || ext4_block_in_group(sb, tmp, block_group))
+		if (ext4_block_in_group(sb, tmp, block_group))
 			ext4_set_bit(EXT4_B2C(sbi, tmp - start), bh->b_data);
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #111 lore raw

PATCH 111/120 ext4: fix false negatives *and* false positives in ext4_check_descriptors()

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

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

From: Theodore Ts'o <[email protected]>

commit 44de022c4382541cebdd6de4465d1f4f465ff1dd upstream.

Ext4_check_descriptors() was getting called before s_gdb_count was initialized. So for file systems w/o the meta_bg feature, allocation bitmaps could overlap the block group descriptors and ext4 wouldn't notice.

For file systems with the meta_bg feature enabled, there was a fencepost error which would cause the ext4_check_descriptors() to incorrectly believe that the block allocation bitmap overlaps with the block group descriptor blocks, and it would reject the mount.

Fix both of these problems.

[bwh: Backported to 3.16: adjust context]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/super.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

fs/ext4/super.c +2 -2

@@ -2064,7 +2064,7 @@ static int ext4_check_descriptors(struct
 	struct ext4_sb_info *sbi = EXT4_SB(sb);
 	ext4_fsblk_t first_block = le32_to_cpu(sbi->s_es->s_first_data_block);
 	ext4_fsblk_t last_block;
-	ext4_fsblk_t last_bg_block = sb_block + ext4_bg_num_gdb(sb, 0) + 1;
+	ext4_fsblk_t last_bg_block = sb_block + ext4_bg_num_gdb(sb, 0);
 	ext4_fsblk_t block_bitmap;
 	ext4_fsblk_t inode_bitmap;
 	ext4_fsblk_t inode_table;

@@ -4018,12 +4018,12 @@ static int ext4_fill_super(struct super_
 			goto failed_mount2;
 		}
 	}
+	sbi->s_gdb_count = db_count;
 	if (!ext4_check_descriptors(sb, logical_sb_block, &first_not_zeroed)) {
 		ext4_msg(sb, KERN_ERR, "group descriptors corrupted!");
 		goto failed_mount2;
 	}
 
-	sbi->s_gdb_count = db_count;
 	get_random_bytes(&sbi->s_next_generation, sizeof(u32));
 	spin_lock_init(&sbi->s_next_gen_lock);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #112 lore raw

PATCH 112/120 ext4: add corruption check in ext4_xattr_set_entry()

https://bugzilla.kernel.org/show_bug.cgi?id=200001

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

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

From: Theodore Ts'o <[email protected]>

commit 5369a762c882c0b6e9599e4ebbb3a9ba9eee7e2d upstream.

In theory this should have been caught earlier when the xattr list was verified, but in case it got missed, it's simple enough to add check to make sure we don't overrun the xattr buffer.

This addresses CVE-2018-10879.

Reviewed-by Andreas Dilger <[email protected]>

[bwh: Backported to 3.16:
- Add inode parameter to ext4_xattr_set_entry() and update callers
- Return -EIO instead of -EFSCORRUPTED on error
- Adjust context]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/xattr.c |   22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

fs/ext4/xattr.c +14 -8

@@ -637,14 +637,20 @@ static size_t ext4_xattr_free_space(stru
 }
 
 static int
-ext4_xattr_set_entry(struct ext4_xattr_info *i, struct ext4_xattr_search *s)
+ext4_xattr_set_entry(struct ext4_xattr_info *i, struct ext4_xattr_search *s,
+		     struct inode *inode)
 {
-	struct ext4_xattr_entry *last;
+	struct ext4_xattr_entry *last, *next;
 	size_t free, min_offs = s->end - s->base, name_len = strlen(i->name);
 
 	/* Compute min_offs and last. */
 	last = s->first;
-	for (; !IS_LAST_ENTRY(last); last = EXT4_XATTR_NEXT(last)) {
+	for (; !IS_LAST_ENTRY(last); last = next) {
+		next = EXT4_XATTR_NEXT(last);
+		if ((void *)next >= s->end) {
+			EXT4_ERROR_INODE(inode, "corrupted xattr entries");
+			return -EIO;
+		}
 		if (!last->e_value_block && last->e_value_size) {
 			size_t offs = le16_to_cpu(last->e_value_offs);
 			if (offs < min_offs)

@@ -825,7 +831,7 @@ ext4_xattr_block_set(handle_t *handle, s
 				ce = NULL;
 			}
 			ea_bdebug(bs->bh, "modifying in-place");
-			error = ext4_xattr_set_entry(i, s);
+			error = ext4_xattr_set_entry(i, s, inode);
 			if (!error) {
 				if (!IS_LAST_ENTRY(s->first))
 					ext4_xattr_rehash(header(s->base),

@@ -877,7 +883,7 @@ ext4_xattr_block_set(handle_t *handle, s
 		s->end = s->base + sb->s_blocksize;
 	}
 
-	error = ext4_xattr_set_entry(i, s);
+	error = ext4_xattr_set_entry(i, s, inode);
 	if (error == -EIO)
 		goto bad_block;
 	if (error)

@@ -1038,7 +1044,7 @@ int ext4_xattr_ibody_inline_set(handle_t
 
 	if (EXT4_I(inode)->i_extra_isize == 0)
 		return -ENOSPC;
-	error = ext4_xattr_set_entry(i, s);
+	error = ext4_xattr_set_entry(i, s, inode);
 	if (error) {
 		if (error == -ENOSPC &&
 		    ext4_has_inline_data(inode)) {

@@ -1050,7 +1056,7 @@ int ext4_xattr_ibody_inline_set(handle_t
 			error = ext4_xattr_ibody_find(inode, i, is);
 			if (error)
 				return error;
-			error = ext4_xattr_set_entry(i, s);
+			error = ext4_xattr_set_entry(i, s, inode);
 		}
 		if (error)
 			return error;

@@ -1076,7 +1082,7 @@ static int ext4_xattr_ibody_set(handle_t
 
 	if (EXT4_I(inode)->i_extra_isize == 0)
 		return -ENOSPC;
-	error = ext4_xattr_set_entry(i, s);
+	error = ext4_xattr_set_entry(i, s, inode);
 	if (error)
 		return error;
 	header = IHDR(inode, ext4_raw_inode(&is->iloc));

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #113 lore raw

PATCH 113/120 ext4: always verify the magic number in xattr blocks

https://bugzilla.kernel.org/show_bug.cgi?id=200001

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

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

From: Theodore Ts'o <[email protected]>

commit 513f86d73855ce556ea9522b6bfd79f87356dc3a upstream.

If there an inode points to a block which is also some other type of metadata block (such as a block allocation bitmap), the buffer_verified flag can be set when it was validated as that other metadata block type; however, it would make a really terrible external attribute block. The reason why we use the verified flag is to avoid constantly reverifying the block. However, it doesn't take much overhead to make sure the magic number of the xattr block is correct, and this will avoid potential crashes.

This addresses CVE-2018-10879.

Reviewed-by Andreas Dilger <[email protected]>

[[email protected]: 3.18 backport: adjust context]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/xattr.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

fs/ext4/xattr.c +3 -3

@@ -218,12 +218,12 @@ ext4_xattr_check_block(struct inode *ino
 {
 	int error;
 
-	if (buffer_verified(bh))
-		return 0;
-
 	if (BHDR(bh)->h_magic != cpu_to_le32(EXT4_XATTR_MAGIC) ||
 	    BHDR(bh)->h_blocks != cpu_to_le32(1))
 		return -EIO;
+	if (buffer_verified(bh))
+		return 0;
+
 	if (!ext4_xattr_block_csum_verify(inode, bh->b_blocknr, BHDR(bh)))
 		return -EIO;
 	error = ext4_xattr_check_names(BFIRST(bh), bh->b_data + bh->b_size,

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #114 lore raw

PATCH 114/120 ext4: never move the system.data xattr out of the inode body

https://bugzilla.kernel.org/show_bug.cgi?id=200005

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

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

From: Theodore Ts'o <[email protected]>

commit 8cdb5240ec5928b20490a2bb34cb87e9a5f40226 upstream.

When expanding the extra isize space, we must never move the system.data xattr out of the inode body. For performance reasons, it doesn't make any sense, and the inline data implementation assumes that system.data xattr is never in the external xattr block.

This addresses CVE-2018-10880

[bwh: Backported to 3.16: adjust context]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/xattr.c |    5 +++++
 1 file changed, 5 insertions(+)

fs/ext4/xattr.c +5 -0

@@ -1391,6 +1391,11 @@ retry:
 		/* Find the entry best suited to be pushed into EA block */
 		entry = NULL;
 		for (; !IS_LAST_ENTRY(last); last = EXT4_XATTR_NEXT(last)) {
+			/* never move system.data out of the inode */
+			if ((last->e_name_len == 4) &&
+			    (last->e_name_index == EXT4_XATTR_INDEX_SYSTEM) &&
+			    !memcmp(last->e_name, "data", 4))
+				continue;
 			total_size =
 			EXT4_XATTR_SIZE(le32_to_cpu(last->e_value_size)) +
 					EXT4_XATTR_LEN(last->e_name_len);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #115 lore raw

PATCH 115/120 ext4: add more inode number paranoia checks

https://bugzilla.kernel.org/show_bug.cgi?id=200069

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

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

From: Theodore Ts'o <[email protected]>

commit c37e9e013469521d9adb932d17a1795c139b36db upstream.

If there is a directory entry pointing to a system inode (such as a journal inode), complain and declare the file system to be corrupted.

Also, if the superblock's first inode number field is too small, refuse to mount the file system.

This addresses CVE-2018-10882.

[bwh: Backported to 3.16: adjust context]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/ext4.h  |    5 -----
 fs/ext4/inode.c |    3 ++-
 fs/ext4/super.c |    5 +++++
 3 files changed, 7 insertions(+), 6 deletions(-)

fs/ext4/ext4.h +0 -5

@@ -1386,11 +1386,6 @@ static inline struct timespec ext4_curre
 static inline int ext4_valid_inum(struct super_block *sb, unsigned long ino)
 {
 	return ino == EXT4_ROOT_INO ||
-		ino == EXT4_USR_QUOTA_INO ||
-		ino == EXT4_GRP_QUOTA_INO ||
-		ino == EXT4_BOOT_LOADER_INO ||
-		ino == EXT4_JOURNAL_INO ||
-		ino == EXT4_RESIZE_INO ||
 		(ino >= EXT4_FIRST_INO(sb) &&
 		 ino <= le32_to_cpu(EXT4_SB(sb)->s_es->s_inodes_count));
 }

fs/ext4/inode.c +2 -1

@@ -3737,7 +3737,8 @@ static int __ext4_get_inode_loc(struct i
 	int			inodes_per_block, inode_offset;
 
 	iloc->bh = NULL;
-	if (!ext4_valid_inum(sb, inode->i_ino))
+	if (inode->i_ino < EXT4_ROOT_INO ||
+	    inode->i_ino > le32_to_cpu(EXT4_SB(sb)->s_es->s_inodes_count))
 		return -EIO;
 
 	iloc->block_group = (inode->i_ino - 1) / EXT4_INODES_PER_GROUP(sb);

fs/ext4/super.c +5 -0

@@ -3794,6 +3794,11 @@ static int ext4_fill_super(struct super_
 	} else {
 		sbi->s_inode_size = le16_to_cpu(es->s_inode_size);
 		sbi->s_first_ino = le32_to_cpu(es->s_first_ino);
+		if (sbi->s_first_ino < EXT4_GOOD_OLD_FIRST_INO) {
+			ext4_msg(sb, KERN_ERR, "invalid first ino: %u",
+				 sbi->s_first_ino);
+			goto failed_mount;
+		}
 		if ((sbi->s_inode_size < EXT4_GOOD_OLD_INODE_SIZE) ||
 		    (!is_power_of_2(sbi->s_inode_size)) ||
 		    (sbi->s_inode_size > blocksize)) {

Greg Kroah-Hartman

author maintainer

2018-10-11 15:40 UTC #116 lore raw

PATCH 116/120 jbd2: dont mark block as modified if the handle is out of credits

https://bugzilla.kernel.org/show_bug.cgi?id=200071

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

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

From: Theodore Ts'o <[email protected]>

commit e09463f220ca9a1a1ecfda84fcda658f99a1f12a upstream.

Do not set the b_modified flag in block's journal head should not until after we're sure that jbd2_journal_dirty_metadat() will not abort with an error due to there not being enough space reserved in the jbd2 handle.

Otherwise, future attempts to modify the buffer may lead a large number of spurious errors and warnings.

This addresses CVE-2018-10883.

[bwh: Backported to 3.16: Drop the added logging statement, as it's on
a code path that doesn't exist here]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/jbd2/transaction.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/jbd2/transaction.c +1 -1

@@ -1283,11 +1283,11 @@ int jbd2_journal_dirty_metadata(handle_t
 		 * of the transaction. This needs to be done
 		 * once a transaction -bzzz
 		 */
-		jh->b_modified = 1;
 		if (handle->h_buffer_credits <= 0) {
 			ret = -ENOSPC;
 			goto out_unlock_bh;
 		}
+		jh->b_modified = 1;
 		handle->h_buffer_credits--;
 	}

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #117 lore raw

PATCH 117/120 ext4: avoid running out of journal credits when appending to an inline file

https://bugzilla.kernel.org/show_bug.cgi?id=200071

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

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

From: Theodore Ts'o <[email protected]>

commit 8bc1379b82b8e809eef77a9fedbb75c6c297be19 upstream.

Use a separate journal transaction if it turns out that we need to convert an inline file to use an data block. Otherwise we could end up failing due to not having journal credits.

This addresses CVE-2018-10883.

[bwh: Backported to 3.16: adjust context]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ext4/ext4.h   |    3 ---
 fs/ext4/inline.c |   38 +-------------------------------------
 fs/ext4/xattr.c  |   18 ++----------------
 3 files changed, 3 insertions(+), 56 deletions(-)

fs/ext4/ext4.h +0 -3

@@ -2663,9 +2663,6 @@ extern struct buffer_head *ext4_get_firs
 extern int ext4_inline_data_fiemap(struct inode *inode,
 				   struct fiemap_extent_info *fieinfo,
 				   int *has_inline);
-extern int ext4_try_to_evict_inline_data(handle_t *handle,
-					 struct inode *inode,
-					 int needed);
 extern void ext4_inline_data_truncate(struct inode *inode, int *has_inline);
 
 extern int ext4_convert_inline_data(struct inode *inode);

fs/ext4/inline.c +1 ~~-37~~

@@ -873,11 +873,11 @@ retry_journal:
 	}
 
 	if (ret == -ENOSPC) {
+		ext4_journal_stop(handle);
 		ret = ext4_da_convert_inline_data_to_extent(mapping,
 							    inode,
 							    flags,
 							    fsdata);
-		ext4_journal_stop(handle);
 		if (ret == -ENOSPC &&
 		    ext4_should_retry_alloc(inode->i_sb, &retries))
 			goto retry_journal;

@@ -1842,42 +1842,6 @@ out:
 	return (error < 0 ? error : 0);
 }
 
-/*
- * Called during xattr set, and if we can sparse space 'needed',
- * just create the extent tree evict the data to the outer block.
- *
- * We use jbd2 instead of page cache to move data to the 1st block
- * so that the whole transaction can be committed as a whole and
- * the data isn't lost because of the delayed page cache write.
- */
-int ext4_try_to_evict_inline_data(handle_t *handle,
-				  struct inode *inode,
-				  int needed)
-{
-	int error;
-	struct ext4_xattr_entry *entry;
-	struct ext4_inode *raw_inode;
-	struct ext4_iloc iloc;
-
-	error = ext4_get_inode_loc(inode, &iloc);
-	if (error)
-		return error;
-
-	raw_inode = ext4_raw_inode(&iloc);
-	entry = (struct ext4_xattr_entry *)((void *)raw_inode +
-					    EXT4_I(inode)->i_inline_off);
-	if (EXT4_XATTR_LEN(entry->e_name_len) +
-	    EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size)) < needed) {
-		error = -ENOSPC;
-		goto out;
-	}
-
-	error = ext4_convert_inline_data_nolock(handle, inode, &iloc);
-out:
-	brelse(iloc.bh);
-	return error;
-}
-
 void ext4_inline_data_truncate(struct inode *inode, int *has_inline)
 {
 	handle_t *handle;

fs/ext4/xattr.c +2 ~~-16~~

@@ -1045,22 +1045,8 @@ int ext4_xattr_ibody_inline_set(handle_t
 	if (EXT4_I(inode)->i_extra_isize == 0)
 		return -ENOSPC;
 	error = ext4_xattr_set_entry(i, s, inode);
-	if (error) {
-		if (error == -ENOSPC &&
-		    ext4_has_inline_data(inode)) {
-			error = ext4_try_to_evict_inline_data(handle, inode,
-					EXT4_XATTR_LEN(strlen(i->name) +
-					EXT4_XATTR_SIZE(i->value_len)));
-			if (error)
-				return error;
-			error = ext4_xattr_ibody_find(inode, i, is);
-			if (error)
-				return error;
-			error = ext4_xattr_set_entry(i, s, inode);
-		}
-		if (error)
-			return error;
-	}
+	if (error)
+		return error;
 	header = IHDR(inode, ext4_raw_inode(&is->iloc));
 	if (!IS_LAST_ENTRY(s->first)) {
 		header->h_magic = cpu_to_le32(EXT4_XATTR_MAGIC);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #118 lore raw

PATCH 118/120 cgroup: Fix deadlock in cpu hotplug path

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

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

From: Prateek Sood <[email protected]>

commit 116d2f7496c51b2e02e8e4ecdd2bdf5fb9d5a641 upstream.

Deadlock during cgroup migration from cpu hotplug path when a task T is being moved from source to destination cgroup.

kworker/0:0
cpuset_hotplug_workfn()
cpuset_hotplug_update_tasks()
hotplug_update_tasks_legacy()
remove_tasks_in_empty_cpuset()
cgroup_transfer_tasks() // stuck in iterator loop
cgroup_migrate()
cgroup_migrate_add_task()

In cgroup_migrate_add_task() it checks for PF_EXITING flag of task T. Task T will not migrate to destination cgroup. css_task_iter_start() will keep pointing to task T in loop waiting for task T cg_list node to be removed.

Task T
do_exit()
exit_signals() // sets PF_EXITING
exit_task_namespaces()
switch_task_namespaces()
free_nsproxy()
put_mnt_ns()
drop_collected_mounts()
namespace_unlock()
synchronize_rcu()
_synchronize_rcu_expedited()
schedule_work() // on cpu0 low priority worker pool wait_event() // waiting for work item to execute

Task T inserted a work item in the worklist of cpu0 low priority worker pool. It is waiting for expedited grace period work item to execute. This work item will only be executed once kworker/0:0 complete execution of cpuset_hotplug_workfn().

kworker/0:0 ==> Task T ==>kworker/0:0

In case of PF_EXITING task being migrated from source to destination cgroup, migrate next available task in source cgroup.

Signed-off-by Prateek Sood <[email protected]>

Signed-off-by Tejun Heo <[email protected]>

[AmitP: Upstream commit cherry-pick failed, so I picked the
backported changes from CAF/msm-4.9 tree instead:
https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?id=49b74f1696417b270c89cd893ca9f37088928078]

Signed-off-by Amit Pundir <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
This patch can be cleanly applied and build tested on 4.4.y and 3.18.y as well but I couldn't find it in msm-4.4 and msm-3.18 trees. So this patch is really untested on those stable trees.
Build tested on 4.9.131, 4.4.159 and 3.18.123 for ARCH=arm/arm64 allmodconfig.

 kernel/cgroup.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

kernel/cgroup.c +5 -1

@@ -3669,7 +3669,11 @@ int cgroup_transfer_tasks(struct cgroup
 	 */
 	do {
 		css_task_iter_start(&from->self, &it);
-		task = css_task_iter_next(&it);
+
+		do {
+			task = css_task_iter_next(&it);
+		} while (task && (task->flags & PF_EXITING));
+
 		if (task)
 			get_task_struct(task);
 		css_task_iter_end(&it);

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #119 lore raw

PATCH 119/120 ubifs: Check for name being NULL while mounting

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

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

From: Richard Weinberger <[email protected]>

commit 37f31b6ca4311b94d985fb398a72e5399ad57925 upstream.

The requested device name can be NULL or an empty string. Check for that and refuse to continue. UBIFS has to do this manually since we cannot use mount_bdev(), which checks for this condition.

Fixes 1e51764a3c2ac ("UBIFS: add new flash file system")

Reported-by [email protected]

Signed-off-by Richard Weinberger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/ubifs/super.c |    3 +++
 1 file changed, 3 insertions(+)

fs/ubifs/super.c +3 -0

@@ -1917,6 +1917,9 @@ static struct ubi_volume_desc *open_ubi(
 	int dev, vol;
 	char *endptr;
 
+	if (!name || !*name)
+		return ERR_PTR(-EINVAL);
+
 	/* First, try to open using the device node path method */
 	ubi = ubi_open_volume_path(name, mode);
 	if (!IS_ERR(ubi))

Greg Kroah-Hartman

author maintainer

2018-10-11 15:41 UTC #120 lore raw

PATCH 120/120 ebtables: arpreply: Add the standard target sanity check

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

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

From: Gao Feng <[email protected]>

commit c953d63548207a085abcb12a15fefc8a11ffdf0a upstream.

The info->target comes from userspace and it would be used directly. So we need to add the sanity check to make sure it is a valid standard target, although the ebtables tool has already checked it. Kernel needs to validate anything coming from userspace.

If the target is set as an evil value, it would break the ebtables and cause a panic. Because the non-standard target is treated as one offset.

Now add one helper function ebt_invalid_target, and we would replace the macro INVALID_TARGET later.

Signed-off-by Gao Feng <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

Cc Loic <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 include/linux/netfilter_bridge/ebtables.h |    5 +++++
 net/bridge/netfilter/ebt_arpreply.c       |    3 +++
 2 files changed, 8 insertions(+)

include/linux/netfilter_bridge/ebtables.h +5 -0

@@ -124,4 +124,9 @@ extern unsigned int ebt_do_table(unsigne
 /* True if the target is not a standard target */
 #define INVALID_TARGET (info->target < -NUM_STANDARD_TARGETS || info->target >= 0)
 
+static inline bool ebt_invalid_target(int target)
+{
+	return (target < -NUM_STANDARD_TARGETS || target >= 0);
+}
+
 #endif

net/bridge/netfilter/ebt_arpreply.c +3 -0

@@ -67,6 +67,9 @@ static int ebt_arpreply_tg_check(const s
 	if (e->ethproto != htons(ETH_P_ARP) ||
 	    e->invflags & EBT_IPROTO)
 		return -EINVAL;
+	if (ebt_invalid_target(info->target))
+		return -EINVAL;
+
 	return 0;
 }

Shuah Khan

2018-10-11 22:46 UTC #121 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 8 lines

	https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.124-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-3.18.y
and the diffstat can be found below.
thanks,
greg k-h

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

thanks,
-- Shuah

Greg Kroah-Hartman

author maintainer

2018-10-12 10:23 UTC #122 lore raw

Quoted 15 lines · Shuah Khan

Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 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/v3.x/stable-review/patch-3.18.124-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-3.18.y
and the diffstat can be found below.

Quoted 5 lines

Quoted 3 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Guenter Roeck

2018-10-12 12:19 UTC #123 lore raw

Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 UTC 2018. Anything received after that time might be too late.

[preliminary]

arm:allmodconfig:

drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:170:5: error: 'LUT_0' undeclared

Guenter

Greg Kroah-Hartman

author maintainer

2018-10-12 13:37 UTC #124 lore raw

Quoted 10 lines · Guenter Roeck

Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 UTC 2018. Anything received after that time might be too late.

Quoted 6 lines

[preliminary]
arm:allmodconfig:
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:170:5: error: 'LUT_0' undeclared

That is really odd in that there are no patches that touch this file, and I do not even see "LUT_0" anywhere in the 3.18.y tree.

strange,

greg k-h

Guenter Roeck

2018-10-12 14:06 UTC #125 lore raw

Quoted 13 lines · Greg Kroah-Hartman

Quoted 12 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 UTC 2018. Anything received after that time might be too late.
[preliminary]

Quoted 8 lines

Quoted 4 lines
arm:allmodconfig:
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:170:5: error: 'LUT_0' undeclared
That is really odd in that there are no patches that touch this file, and I do not even see "LUT_0" anywhere in the 3.18.y tree.

Bisect:

# bad: [8c4ca12b60ea371a32db58cf78b6cb4e2ba4515c] Linux 3.18.124-rc1
# good: [921b2fed6a79439ef1609ef4af0ada5cccb3555c] Linux 3.18.123
git bisect start 'HEAD' 'v3.18.123'
# good: [aed5b0190528303a3f4d319f95d7e38c94ca32ab] USB: remove LPM management from usb_driver_claim_interface() git bisect good aed5b0190528303a3f4d319f95d7e38c94ca32ab
# good: [10441f560c0ad0aeed00402088d71d4d299d6537] r8169: Clear RTL_FLAG_TASK_*_PENDING when clearing RTL_FLAG_TASK_ENABLED git bisect good 10441f560c0ad0aeed00402088d71d4d299d6537
# bad: [0661a919177560337d962f43daa46dde2fa4d89e] mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys git bisect bad 0661a919177560337d962f43daa46dde2fa4d89e
# good: [d4b130cc92bbef445de4ffe4ecd068935375d591] ocfs2: fix locking for res->tracking and dlm->tracking_list git bisect good d4b130cc92bbef445de4ffe4ecd068935375d591
# bad: [1f002a3e6d7250a62966399bd91eeec308c0b756] fbdev/omapfb: fix omapfb_memory_read infoleak
git bisect bad 1f002a3e6d7250a62966399bd91eeec308c0b756
# bad: [5396a79f029d54c1e02409335c7dfde43c55e4a4] Make file credentials available to the seqfile interfaces git bisect bad 5396a79f029d54c1e02409335c7dfde43c55e4a4
# good: [7da4d144b6922e94aad8c0d405e4cc63a44b8ec5] dm thin metadata: fix __udivdi3 undefined on 32-bit git bisect good 7da4d144b6922e94aad8c0d405e4cc63a44b8ec5

# first bad commit: [5396a79f029d54c1e02409335c7dfde43c55e4a4] Make file credentials available to the seqfile interfaces

... and reverting that patch fixes the problem. No idea why; maybe because of include file changes.

Guenter

Greg Kroah-Hartman

author maintainer

2018-10-12 14:21 UTC #126 lore raw

Quoted 43 lines · Guenter Roeck

Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 UTC 2018. Anything received after that time might be too late.
[preliminary]
Quoted 8 lines
Quoted 4 lines
arm:allmodconfig:
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:170:5: error: 'LUT_0' undeclared
That is really odd in that there are no patches that touch this file, and I do not even see "LUT_0" anywhere in the 3.18.y tree.
Bisect:
# bad: [8c4ca12b60ea371a32db58cf78b6cb4e2ba4515c] Linux 3.18.124-rc1
# good: [921b2fed6a79439ef1609ef4af0ada5cccb3555c] Linux 3.18.123
git bisect start 'HEAD' 'v3.18.123'
# good: [aed5b0190528303a3f4d319f95d7e38c94ca32ab] USB: remove LPM management from usb_driver_claim_interface() git bisect good aed5b0190528303a3f4d319f95d7e38c94ca32ab
# good: [10441f560c0ad0aeed00402088d71d4d299d6537] r8169: Clear RTL_FLAG_TASK_*_PENDING when clearing RTL_FLAG_TASK_ENABLED git bisect good 10441f560c0ad0aeed00402088d71d4d299d6537
# bad: [0661a919177560337d962f43daa46dde2fa4d89e] mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys git bisect bad 0661a919177560337d962f43daa46dde2fa4d89e
# good: [d4b130cc92bbef445de4ffe4ecd068935375d591] ocfs2: fix locking for res->tracking and dlm->tracking_list git bisect good d4b130cc92bbef445de4ffe4ecd068935375d591
# bad: [1f002a3e6d7250a62966399bd91eeec308c0b756] fbdev/omapfb: fix omapfb_memory_read infoleak
git bisect bad 1f002a3e6d7250a62966399bd91eeec308c0b756
# bad: [5396a79f029d54c1e02409335c7dfde43c55e4a4] Make file credentials available to the seqfile interfaces git bisect bad 5396a79f029d54c1e02409335c7dfde43c55e4a4
# good: [7da4d144b6922e94aad8c0d405e4cc63a44b8ec5] dm thin metadata: fix __udivdi3 undefined on 32-bit git bisect good 7da4d144b6922e94aad8c0d405e4cc63a44b8ec5

Quoted 4 lines

# first bad commit: [5396a79f029d54c1e02409335c7dfde43c55e4a4] Make file credentials available to the seqfile interfaces
... and reverting that patch fixes the problem. No idea why; maybe because of include file changes.

That patch _adds_ two .h files to be included in
include/linux/seq_file.h, not removes any.

Ugh, that's a mess.

I've seen the LUT_0 thing show up a long time ago due to some other odd arm thing. But I don't remember how it was ever resolved. Maybe I'll just let this one go and see if anyone notices :)

thanks,

greg k-h

Guenter Roeck

2018-10-12 15:15 UTC #127 lore raw

Quoted 49 lines · Greg Kroah-Hartman

Quoted 43 lines · Guenter Roeck
Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 UTC 2018. Anything received after that time might be too late.
[preliminary]
Quoted 8 lines
Quoted 4 lines
arm:allmodconfig:
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:170:5: error: 'LUT_0' undeclared
That is really odd in that there are no patches that touch this file, and I do not even see "LUT_0" anywhere in the 3.18.y tree.
Bisect:
# bad: [8c4ca12b60ea371a32db58cf78b6cb4e2ba4515c] Linux 3.18.124-rc1
# good: [921b2fed6a79439ef1609ef4af0ada5cccb3555c] Linux 3.18.123
git bisect start 'HEAD' 'v3.18.123'
# good: [aed5b0190528303a3f4d319f95d7e38c94ca32ab] USB: remove LPM management from usb_driver_claim_interface() git bisect good aed5b0190528303a3f4d319f95d7e38c94ca32ab
# good: [10441f560c0ad0aeed00402088d71d4d299d6537] r8169: Clear RTL_FLAG_TASK_*_PENDING when clearing RTL_FLAG_TASK_ENABLED git bisect good 10441f560c0ad0aeed00402088d71d4d299d6537
# bad: [0661a919177560337d962f43daa46dde2fa4d89e] mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys git bisect bad 0661a919177560337d962f43daa46dde2fa4d89e
# good: [d4b130cc92bbef445de4ffe4ecd068935375d591] ocfs2: fix locking for res->tracking and dlm->tracking_list git bisect good d4b130cc92bbef445de4ffe4ecd068935375d591
# bad: [1f002a3e6d7250a62966399bd91eeec308c0b756] fbdev/omapfb: fix omapfb_memory_read infoleak
git bisect bad 1f002a3e6d7250a62966399bd91eeec308c0b756
# bad: [5396a79f029d54c1e02409335c7dfde43c55e4a4] Make file credentials available to the seqfile interfaces git bisect bad 5396a79f029d54c1e02409335c7dfde43c55e4a4
# good: [7da4d144b6922e94aad8c0d405e4cc63a44b8ec5] dm thin metadata: fix __udivdi3 undefined on 32-bit git bisect good 7da4d144b6922e94aad8c0d405e4cc63a44b8ec5
Quoted 4 lines
# first bad commit: [5396a79f029d54c1e02409335c7dfde43c55e4a4] Make file credentials available to the seqfile interfaces
... and reverting that patch fixes the problem. No idea why; maybe because of include file changes.

Quoted 9 lines

That patch _adds_ two .h files to be included in
include/linux/seq_file.h, not removes any.
Ugh, that's a mess.
I've seen the LUT_0 thing show up a long time ago due to some other odd arm thing. But I don't remember how it was ever resolved. Maybe I'll just let this one go and see if anyone notices :)

See commit 04850c4d8613127a9b488321c0ad83bff7519311. I'll check if it applies and fixes the problem, and let you know.

Guenter

Guenter Roeck

2018-10-12 15:39 UTC #128 lore raw

Quoted 53 lines · Guenter Roeck

Quoted 52 lines · Greg Kroah-Hartman
Quoted 43 lines · Guenter Roeck
Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 UTC 2018. Anything received after that time might be too late.
[preliminary]
Quoted 8 lines
Quoted 4 lines
arm:allmodconfig:
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:170:5: error: 'LUT_0' undeclared
That is really odd in that there are no patches that touch this file, and I do not even see "LUT_0" anywhere in the 3.18.y tree.
Bisect:
# bad: [8c4ca12b60ea371a32db58cf78b6cb4e2ba4515c] Linux 3.18.124-rc1
# good: [921b2fed6a79439ef1609ef4af0ada5cccb3555c] Linux 3.18.123
git bisect start 'HEAD' 'v3.18.123'
# good: [aed5b0190528303a3f4d319f95d7e38c94ca32ab] USB: remove LPM management from usb_driver_claim_interface() git bisect good aed5b0190528303a3f4d319f95d7e38c94ca32ab
# good: [10441f560c0ad0aeed00402088d71d4d299d6537] r8169: Clear RTL_FLAG_TASK_*_PENDING when clearing RTL_FLAG_TASK_ENABLED git bisect good 10441f560c0ad0aeed00402088d71d4d299d6537
# bad: [0661a919177560337d962f43daa46dde2fa4d89e] mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys git bisect bad 0661a919177560337d962f43daa46dde2fa4d89e
# good: [d4b130cc92bbef445de4ffe4ecd068935375d591] ocfs2: fix locking for res->tracking and dlm->tracking_list git bisect good d4b130cc92bbef445de4ffe4ecd068935375d591
# bad: [1f002a3e6d7250a62966399bd91eeec308c0b756] fbdev/omapfb: fix omapfb_memory_read infoleak
git bisect bad 1f002a3e6d7250a62966399bd91eeec308c0b756
# bad: [5396a79f029d54c1e02409335c7dfde43c55e4a4] Make file credentials available to the seqfile interfaces git bisect bad 5396a79f029d54c1e02409335c7dfde43c55e4a4
# good: [7da4d144b6922e94aad8c0d405e4cc63a44b8ec5] dm thin metadata: fix __udivdi3 undefined on 32-bit git bisect good 7da4d144b6922e94aad8c0d405e4cc63a44b8ec5
Quoted 4 lines
# first bad commit: [5396a79f029d54c1e02409335c7dfde43c55e4a4] Make file credentials available to the seqfile interfaces
... and reverting that patch fixes the problem. No idea why; maybe because of include file changes.
That patch _adds_ two .h files to be included in
include/linux/seq_file.h, not removes any.

Quoted 9 lines

Quoted 6 lines
Ugh, that's a mess.
I've seen the LUT_0 thing show up a long time ago due to some other odd arm thing. But I don't remember how it was ever resolved. Maybe I'll just let this one go and see if anyone notices :)
See commit 04850c4d8613127a9b488321c0ad83bff7519311. I'll check if it applies and fixes the problem, and let you know.

I confirmed that commit 04850c4d86131 applies and fixes the problem.

Guenter

Greg Kroah-Hartman

author maintainer

2018-10-12 16:05 UTC #129 lore raw

Quoted 56 lines · Guenter Roeck

Quoted 55 lines · Guenter Roeck
Quoted 54 lines · Greg Kroah-Hartman
Quoted 43 lines · Guenter Roeck
Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 UTC 2018. Anything received after that time might be too late.
[preliminary]
Quoted 8 lines
Quoted 4 lines
arm:allmodconfig:
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:170:5: error: 'LUT_0' undeclared
That is really odd in that there are no patches that touch this file, and I do not even see "LUT_0" anywhere in the 3.18.y tree.
Bisect:
# bad: [8c4ca12b60ea371a32db58cf78b6cb4e2ba4515c] Linux 3.18.124-rc1
# good: [921b2fed6a79439ef1609ef4af0ada5cccb3555c] Linux 3.18.123
git bisect start 'HEAD' 'v3.18.123'
# good: [aed5b0190528303a3f4d319f95d7e38c94ca32ab] USB: remove LPM management from usb_driver_claim_interface() git bisect good aed5b0190528303a3f4d319f95d7e38c94ca32ab
# good: [10441f560c0ad0aeed00402088d71d4d299d6537] r8169: Clear RTL_FLAG_TASK_*_PENDING when clearing RTL_FLAG_TASK_ENABLED git bisect good 10441f560c0ad0aeed00402088d71d4d299d6537
# bad: [0661a919177560337d962f43daa46dde2fa4d89e] mac80211: fix setting IEEE80211_KEY_FLAG_RX_MGMT for AP mode keys git bisect bad 0661a919177560337d962f43daa46dde2fa4d89e
# good: [d4b130cc92bbef445de4ffe4ecd068935375d591] ocfs2: fix locking for res->tracking and dlm->tracking_list git bisect good d4b130cc92bbef445de4ffe4ecd068935375d591
# bad: [1f002a3e6d7250a62966399bd91eeec308c0b756] fbdev/omapfb: fix omapfb_memory_read infoleak
git bisect bad 1f002a3e6d7250a62966399bd91eeec308c0b756
# bad: [5396a79f029d54c1e02409335c7dfde43c55e4a4] Make file credentials available to the seqfile interfaces git bisect bad 5396a79f029d54c1e02409335c7dfde43c55e4a4
# good: [7da4d144b6922e94aad8c0d405e4cc63a44b8ec5] dm thin metadata: fix __udivdi3 undefined on 32-bit git bisect good 7da4d144b6922e94aad8c0d405e4cc63a44b8ec5
Quoted 4 lines
# first bad commit: [5396a79f029d54c1e02409335c7dfde43c55e4a4] Make file credentials available to the seqfile interfaces
... and reverting that patch fixes the problem. No idea why; maybe because of include file changes.
That patch _adds_ two .h files to be included in
include/linux/seq_file.h, not removes any.
Ugh, that's a mess.

Quoted 8 lines

Quoted 7 lines
Quoted 4 lines
I've seen the LUT_0 thing show up a long time ago due to some other odd arm thing. But I don't remember how it was ever resolved. Maybe I'll just let this one go and see if anyone notices :)
See commit 04850c4d8613127a9b488321c0ad83bff7519311. I'll check if it applies and fixes the problem, and let you know.
I confirmed that commit 04850c4d86131 applies and fixes the problem.

Great, now queued up, thanks!

greg k-h

Nathan Chancellor

2018-10-12 17:07 UTC #130 lore raw

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 9 lines

	https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.124-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-3.18.y
and the diffstat can be found below.
thanks,
greg k-h

Merged, compiled with -Werror, and installed onto my Pixel XL.

No initial issues noticed in dmesg or general usage.

Thanks!
Nathan

Greg Kroah-Hartman

author maintainer

2018-10-13 06:42 UTC #131 lore raw

Quoted 15 lines · Nathan Chancellor

Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.18.124 release. There are 120 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 Sat Oct 13 15:25:29 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/v3.x/stable-review/patch-3.18.124-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-3.18.y
and the diffstat can be found below.

Quoted 8 lines

Quoted 4 lines
thanks,
greg k-h
Merged, compiled with -Werror, and installed onto my Pixel XL.
No initial issues noticed in dmesg or general usage.

Thanks for testing 3 of these and letting me know.

greg k-h

Guenter Roeck

2018-10-12 20:24 UTC #132 lore raw