Skip to contentSkip to conversation

3.18.67-stable review

PATCH In review Greg Kroah-Hartman 3 participants 14 messages Aug 22, 2017 – Aug 28, 2017 Stable branch

lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 3.18.67-stable review

This is the start of the stable review cycle for the 3.18.67 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu Aug 24 19:08:42 UTC 2017. Anything received after that time might be too late.

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

	kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.67-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

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

Greg Kroah-Hartman <[email protected]>

    Linux 3.18.67-rc1

Hector Martin <[email protected]>
usb: qmi_wwan: add D-Link DWM-222 device ID

Oleg Nesterov <[email protected]>
pids: make task_tgid_nr_ns() safe

Linus Torvalds <[email protected]>
Sanitize 'move_pages()' permission checks

Boris Brezillon <[email protected]>
irqchip/atmel-aic: Fix unbalanced refcount in aic_common_rtc_irq_fixup()

Boris Brezillon <[email protected]>
irqchip/atmel-aic: Fix unbalanced of_node_put() in aic_common_irq_fixup()

zhong jiang <[email protected]>
mm/mempolicy: fix use after free when calling get_mempolicy

Takashi Iwai <[email protected]>
ALSA: usb-audio: Apply sample rate quirk to Sennheiser headset

Thomas Bogendoerfer <[email protected]>
parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo

Jan Kara <[email protected]>
audit: Fix use after free in audit_remove_watch_rule()

Liping Zhang <[email protected]>
netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister

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

Diffstat:

 Makefile                               |  4 +--
 drivers/irqchip/irq-atmel-aic-common.c |  5 ++--
 drivers/net/usb/qmi_wwan.c             |  1 +
 drivers/parisc/dino.c                  |  2 +-
 include/linux/pid.h                    |  4 ++-
 include/linux/sched.h                  | 50 ++++++++++++++++++----------------
 kernel/audit_watch.c                   | 12 ++++----
 kernel/pid.c                           | 11 +++-----
 mm/mempolicy.c                         |  5 ----
 mm/migrate.c                           | 11 ++------
 net/netfilter/nf_conntrack_extend.c    | 13 +++++++--
 sound/usb/quirks.c                     |  1 +
 12 files changed, 61 insertions(+), 58 deletions(-)
author maintainer
#1 lore raw

PATCH 1/10 netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister

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

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

From: Liping Zhang <[email protected]>

commit 9c3f3794926a997b1cab6c42480ff300efa2d162 upstream.

If one cpu is doing nf_ct_extend_unregister while another cpu is doing __nf_ct_ext_add_length, then we may hit BUG_ON(t == NULL). Moreover, there's no synchronize_rcu invocation after set nf_ct_ext_types[id] to NULL, so it's possible that we may access invalid pointer.

But actually, most of the ct extends are built-in, so the problem listed above will not happen. However, there are two exceptions: NF_CT_EXT_NAT and NF_CT_EXT_SYNPROXY.

For _EXT_NAT, the panic will not happen, since adding the nat extend and unregistering the nat extend are located in the same file(nf_nat_core.c), this means that after the nat module is removed, we cannot add the nat extend too.

For _EXT_SYNPROXY, synproxy extend may be added by init_conntrack, while synproxy extend unregister will be done by synproxy_core_exit. So after nf_synproxy_core.ko is removed, we may still try to add the synproxy extend, then kernel panic may happen.

I know it's very hard to reproduce this issue, but I can play a tricky game to make it happen very easily :)

Step 1. Enable SYNPROXY for tcp dport 1234 at FORWARD hook:

  # iptables -I FORWARD -p tcp --dport 1234 -j SYNPROXY
Step 2. Queue the syn packet to the userspace at raw table OUTPUT hook.
        Also note, in the userspace we only add a 20s' delay, then
        reinject the syn packet to the kernel:
  # iptables -t raw -I OUTPUT -p tcp --syn -j NFQUEUE --queue-num 1
Step 3. Using "nc 2.2.2.2 1234" to connect the server.
Step 4. Now remove the nf_synproxy_core.ko quickly:
  # iptables -F FORWARD
  # rmmod ipt_SYNPROXY
  # rmmod nf_synproxy_core
Step 5. After 20s' delay, the syn packet is reinjected to the kernel.

Now you will see the panic like this:
kernel BUG at net/netfilter/nf_conntrack_extend.c:91!

  Call Trace:
   ? __nf_ct_ext_add_length+0x53/0x3c0 [nf_conntrack]
   init_conntrack+0x12b/0x600 [nf_conntrack]
   nf_conntrack_in+0x4cc/0x580 [nf_conntrack]
   ipv4_conntrack_local+0x48/0x50 [nf_conntrack_ipv4]
   nf_reinject+0x104/0x270
   nfqnl_recv_verdict+0x3e1/0x5f9 [nfnetlink_queue]
   ? nfqnl_recv_verdict+0x5/0x5f9 [nfnetlink_queue]
   ? nla_parse+0xa0/0x100
   nfnetlink_rcv_msg+0x175/0x6a9 [nfnetlink]
   [...]

One possible solution is to make NF_CT_EXT_SYNPROXY extend built-in, i.e. introduce nf_conntrack_synproxy.c and only do ct extend register and unregister in it, similar to nf_conntrack_timeout.c.

But having such a obscure restriction of nf_ct_extend_unregister is not a good idea, so we should invoke synchronize_rcu after set nf_ct_ext_types to NULL, and check the NULL pointer when do __nf_ct_ext_add_length. Then it will be easier if we add new ct extend in the future.

Last, we use kfree_rcu to free nf_ct_ext, so rcu_barrier() is unnecessary anymore, remove it too.

---
 net/netfilter/nf_conntrack_extend.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)
net/netfilter/nf_conntrack_extend.c +10 -3
@@ -53,7 +53,11 @@ nf_ct_ext_create(struct nf_ct_ext **ext,
 
 	rcu_read_lock();
 	t = rcu_dereference(nf_ct_ext_types[id]);
-	BUG_ON(t == NULL);
+	if (!t) {
+		rcu_read_unlock();
+		return NULL;
+	}
+
 	off = ALIGN(sizeof(struct nf_ct_ext), t->align);
 	len = off + t->len + var_alloc_len;
 	alloc_size = t->alloc_size + var_alloc_len;
@@ -88,7 +92,10 @@ void *__nf_ct_ext_add_length(struct nf_c
 
 	rcu_read_lock();
 	t = rcu_dereference(nf_ct_ext_types[id]);
-	BUG_ON(t == NULL);
+	if (!t) {
+		rcu_read_unlock();
+		return NULL;
+	}
 
 	newoff = ALIGN(old->len, t->align);
 	newlen = newoff + t->len + var_alloc_len;
@@ -186,6 +193,6 @@ void nf_ct_extend_unregister(struct nf_c
 	RCU_INIT_POINTER(nf_ct_ext_types[type->id], NULL);
 	update_alloc_size(type);
 	mutex_unlock(&nf_ct_ext_type_mutex);
-	rcu_barrier(); /* Wait for completion of call_rcu()'s */
+	synchronize_rcu();
 }
 EXPORT_SYMBOL_GPL(nf_ct_extend_unregister);
author maintainer
#2 lore raw

PATCH 2/10 audit: Fix use after free in audit_remove_watch_rule()

In reply to Greg Kroah-Hartman

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

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

From: Jan Kara <[email protected]>

commit d76036ab47eafa6ce52b69482e91ca3ba337d6d6 upstream.

audit_remove_watch_rule() drops watch's reference to parent but then continues to work with it. That is not safe as parent can get freed once we drop our reference. The following is a trivial reproducer:

mount -o loop image /mnt
touch /mnt/file
auditctl -w /mnt/file -p wax
umount /mnt
auditctl -D
<crash in fsnotify_destroy_mark()>

Grab our own reference in audit_remove_watch_rule() earlier to make sure mark does not get freed under us.

---
 kernel/audit_watch.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)
kernel/audit_watch.c +7 -5
@@ -455,13 +455,15 @@ void audit_remove_watch_rule(struct audi
 	list_del(&krule->rlist);
 
 	if (list_empty(&watch->rules)) {
+		/*
+		 * audit_remove_watch() drops our reference to 'parent' which
+		 * can get freed. Grab our own reference to be safe.
+		 */
+		audit_get_parent(parent);
 		audit_remove_watch(watch);
-
-		if (list_empty(&parent->watches)) {
-			audit_get_parent(parent);
+		if (list_empty(&parent->watches))
 			fsnotify_destroy_mark(&parent->mark, audit_watch_group);
-			audit_put_parent(parent);
-		}
+		audit_put_parent(parent);
 	}
 }
 
author maintainer
#3 lore raw

PATCH 3/10 parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo

In reply to Greg Kroah-Hartman

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

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

From: Thomas Bogendoerfer <[email protected]>

commit 4098116039911e8870d84c975e2ec22dab65a909 upstream.

For 64bit kernels the lmmio_space_offset of the host bridge window isn't set correctly on systems with dino/cujo PCI host bridges. This leads to not assigned memory bars and failing drivers, which need to use these bars.

---
 drivers/parisc/dino.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/parisc/dino.c +1 -1
@@ -954,7 +954,7 @@ static int __init dino_probe(struct pari
 
 	dino_dev->hba.dev = dev;
 	dino_dev->hba.base_addr = ioremap_nocache(hpa, 4096);
-	dino_dev->hba.lmmio_space_offset = 0;	/* CPU addrs == bus addrs */
+	dino_dev->hba.lmmio_space_offset = PCI_F_EXTEND;
 	spin_lock_init(&dino_dev->dinosaur_pen);
 	dino_dev->hba.iommu = ccio_get_iommu(dev);
 
author maintainer
#4 lore raw

PATCH 4/10 ALSA: usb-audio: Apply sample rate quirk to Sennheiser headset

In reply to Greg Kroah-Hartman

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

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

From: Takashi Iwai <[email protected]>

commit a8e800fe0f68bc28ce309914f47e432742b865ed upstream.

A Senheisser headset requires the typical sample-rate quirk for avoiding spurious errors from inquiring the current sample rate like:
usb 1-1: 2:1: cannot get freq at ep 0x4
usb 1-1: 3:1: cannot get freq at ep 0x83

The USB ID 1395:740a has to be added to the entries in snd_usb_get_sample_rate_quirk().

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1052580

---
 sound/usb/quirks.c |    1 +
 1 file changed, 1 insertion(+)
sound/usb/quirks.c +1 -0
@@ -1127,6 +1127,7 @@ bool snd_usb_get_sample_rate_quirk(struc
 	case USB_ID(0x04D8, 0xFEEA): /* Benchmark DAC1 Pre */
 	case USB_ID(0x0556, 0x0014): /* Phoenix Audio TMX320VC */
 	case USB_ID(0x074D, 0x3553): /* Outlaw RR2150 (Micronas UAC3553B) */
+	case USB_ID(0x1395, 0x740a): /* Sennheiser DECT */
 	case USB_ID(0x1901, 0x0191): /* GE B850V3 CP2114 audio interface */
 	case USB_ID(0x1de7, 0x0013): /* Phoenix Audio MT202exe */
 	case USB_ID(0x1de7, 0x0014): /* Phoenix Audio TMX320 */
author maintainer
#5 lore raw

PATCH 5/10 mm/mempolicy: fix use after free when calling get_mempolicy

In reply to Greg Kroah-Hartman

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

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

From: zhong jiang <[email protected]>

commit 73223e4e2e3867ebf033a5a8eb2e5df0158ccc99 upstream.

I hit a use after free issue when executing trinity and repoduced it with KASAN enabled. The related call trace is as follows.

  BUG: KASan: use after free in SyS_get_mempolicy+0x3c8/0x960 at addr ffff8801f582d766
  Read of size 2 by task syz-executor1/798

INFO: Allocated in mpol_new.part.2+0x74/0x160 age=3 cpu=1 pid=799

     __slab_alloc+0x768/0x970
     kmem_cache_alloc+0x2e7/0x450
     mpol_new.part.2+0x74/0x160
     mpol_new+0x66/0x80
     SyS_mbind+0x267/0x9f0
     system_call_fastpath+0x16/0x1b
  INFO: Freed in __mpol_put+0x2b/0x40 age=4 cpu=1 pid=799
     __slab_free+0x495/0x8e0
     kmem_cache_free+0x2f3/0x4c0
     __mpol_put+0x2b/0x40
     SyS_mbind+0x383/0x9f0
     system_call_fastpath+0x16/0x1b
  INFO: Slab 0xffffea0009cb8dc0 objects=23 used=8 fp=0xffff8801f582de40 flags=0x200000000004080
  INFO: Object 0xffff8801f582d760 @offset=5984 fp=0xffff8801f582d600

Bytes b4 ffff8801f582d750: ae 01 ff ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ Object ffff8801f582d760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8801f582d770: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk.
Redzone ffff8801f582d778: bb bb bb bb bb bb bb bb ........
Padding ffff8801f582d8b8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ

  Memory state around the buggy address:
  ffff8801f582d600: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff8801f582d680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  >ffff8801f582d700: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fc

!shared memory policy is not protected against parallel removal by other thread which is normally protected by the mmap_sem. do_get_mempolicy, however, drops the lock midway while we can still access it later.

Early premature up_read is a historical artifact from times when put_user was called in this path see https://lwn.net/Articles/124754/
but that is gone since 8bccd85ffbaf ("[PATCH] Implement sys_* do_* layering in the memory policy layer."). but when we have the the current mempolicy ref count model. The issue was introduced accordingly.

Fix the issue by removing the premature release.

---
 mm/mempolicy.c |    5 -----
 1 file changed, 5 deletions(-)
mm/mempolicy.c +0 -5
@@ -944,11 +944,6 @@ static long do_get_mempolicy(int *policy
 		*policy |= (pol->flags & MPOL_MODE_FLAGS);
 	}
 
-	if (vma) {
-		up_read(&current->mm->mmap_sem);
-		vma = NULL;
-	}
-
 	err = 0;
 	if (nmask) {
 		if (mpol_store_user_nodemask(pol)) {
author maintainer
#6 lore raw

PATCH 6/10 irqchip/atmel-aic: Fix unbalanced of_node_put() in aic_common_irq_fixup()

In reply to Greg Kroah-Hartman

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

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

From: Boris Brezillon <[email protected]>

commit 469bcef53c546bb792aa66303933272991b7831d upstream.

aic_common_irq_fixup() is calling twice of_node_put() on the same node thus leading to an unbalanced refcount on the root node.

Fixes b2f579b58e93 ("irqchip: atmel-aic: Add irq fixup infrastructure")
---
 drivers/irqchip/irq-atmel-aic-common.c |    1 -
 1 file changed, 1 deletion(-)
drivers/irqchip/irq-atmel-aic-common.c +0 -1
@@ -176,7 +176,6 @@ void __init aic_common_irq_fixup(const s
 		return;
 
 	match = of_match_node(matches, root);
-	of_node_put(root);
 
 	if (match) {
 		void (*fixup)(struct device_node *) = match->data;
author maintainer
#7 lore raw

PATCH 7/10 irqchip/atmel-aic: Fix unbalanced refcount in aic_common_rtc_irq_fixup()

In reply to Greg Kroah-Hartman

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

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

From: Boris Brezillon <[email protected]>

commit 277867ade8262583f4280cadbe90e0031a3706a7 upstream.

of_find_compatible_node() is calling of_node_put() on its first argument thus leading to an unbalanced of_node_get/put() issue if the node has not been retained before that.

Instead of passing the root node, pass NULL, which does exactly the same:
iterate over all DT nodes, starting from the root node.

Fixes 3d61467f9bab ("irqchip: atmel-aic: Implement RTC irq fixup")
---
 drivers/irqchip/irq-atmel-aic-common.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/irqchip/irq-atmel-aic-common.c +2 -2
@@ -148,9 +148,9 @@ void __init aic_common_rtc_irq_fixup(str
 	struct device_node *np;
 	void __iomem *regs;
 
-	np = of_find_compatible_node(root, NULL, "atmel,at91rm9200-rtc");
+	np = of_find_compatible_node(NULL, NULL, "atmel,at91rm9200-rtc");
 	if (!np)
-		np = of_find_compatible_node(root, NULL,
+		np = of_find_compatible_node(NULL, NULL,
 					     "atmel,at91sam9x5-rtc");
 
 	if (!np)
author maintainer
#8 lore raw

PATCH 8/10 Sanitize move_pages() permission checks

In reply to Greg Kroah-Hartman

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

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

From: Linus Torvalds <[email protected]>

commit 197e7e521384a23b9e585178f3f11c9fa08274b9 upstream.

The 'move_paghes()' system call was introduced long long ago with the same permission checks as for sending a signal (except using CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability).

That turns out to not be a great choice - while the system call really only moves physical page allocations around (and you need other capabilities to do a lot of it), you can check the return value to map out some the virtual address choices and defeat ASLR of a binary that still shares your uid.

So change the access checks to the more common 'ptrace_may_access()' model instead.

This tightens the access checks for the uid, and also effectively changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that anybody really _uses_ this legacy system call any more (we hav ebetter NUMA placement models these days), so I expect nobody to notice.

Famous last words.

---
 mm/migrate.c |   13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)
mm/migrate.c +4 -9
@@ -37,6 +37,7 @@
 #include <linux/gfp.h>
 #include <linux/balloon_compaction.h>
 #include <linux/mmu_notifier.h>
+#include <linux/ptrace.h>
 
 #include <asm/tlbflush.h>
 
@@ -1468,7 +1469,6 @@ SYSCALL_DEFINE6(move_pages, pid_t, pid,
 		const int __user *, nodes,
 		int __user *, status, int, flags)
 {
-	const struct cred *cred = current_cred(), *tcred;
 	struct task_struct *task;
 	struct mm_struct *mm;
 	int err;
@@ -1492,14 +1492,9 @@ SYSCALL_DEFINE6(move_pages, pid_t, pid,
 
 	/*
 	 * Check if this process has the right to modify the specified
-	 * process. The right exists if the process has administrative
-	 * capabilities, superuser privileges or the same
-	 * userid as the target process.
-	 */
-	tcred = __task_cred(task);
-	if (!uid_eq(cred->euid, tcred->suid) && !uid_eq(cred->euid, tcred->uid) &&
-	    !uid_eq(cred->uid,  tcred->suid) && !uid_eq(cred->uid,  tcred->uid) &&
-	    !capable(CAP_SYS_NICE)) {
+	 * process. Use the regular "ptrace_may_access()" checks.
+	 */
+	if (!ptrace_may_access(task, PTRACE_MODE_READ_REALCREDS)) {
 		rcu_read_unlock();
 		err = -EPERM;
 		goto out;
author maintainer
#9 lore raw

PATCH 9/10 pids: make task_tgid_nr_ns() safe

In reply to Greg Kroah-Hartman

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

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

From: Oleg Nesterov <[email protected]>

commit dd1c1f2f2028a7b851f701fc6a8ebe39dcb95e7c upstream.

This was reported many times, and this was even mentioned in commit 52ee2dfdd4f5 ("pids: refactor vnr/nr_ns helpers to make them safe") but somehow nobody bothered to fix the obvious problem: task_tgid_nr_ns() is not safe because task->group_leader points to nowhere after the exiting task passes exit_notify(), rcu_read_lock() can not help.

We really need to change __unhash_process() to nullify group_leader, parent, and real_parent, but this needs some cleanups. Until then we can turn task_tgid_nr_ns() into another user of __task_pid_nr_ns() and fix the problem.

---
 include/linux/pid.h   |    4 +++-
 include/linux/sched.h |   50 +++++++++++++++++++++++++++-----------------------
 kernel/pid.c          |   11 ++++-------
 3 files changed, 34 insertions(+), 31 deletions(-)
include/linux/pid.h +3 -1
@@ -8,7 +8,9 @@ enum pid_type
 	PIDTYPE_PID,
 	PIDTYPE_PGID,
 	PIDTYPE_SID,
-	PIDTYPE_MAX
+	PIDTYPE_MAX,
+	/* only valid to __task_pid_nr_ns() */
+	__PIDTYPE_TGID
 };
 
 /*
include/linux/sched.h +27 -23

64 lines not on this page · raw message

kernel/pid.c +4 -7
@@ -523,8 +523,11 @@ pid_t __task_pid_nr_ns(struct task_struc
 	if (!ns)
 		ns = task_active_pid_ns(current);
 	if (likely(pid_alive(task))) {
-		if (type != PIDTYPE_PID)
+		if (type != PIDTYPE_PID) {
+			if (type == __PIDTYPE_TGID)
+				type = PIDTYPE_PID;
 			task = task->group_leader;
+		}
 		nr = pid_nr_ns(task->pids[type].pid, ns);
 	}
 	rcu_read_unlock();
@@ -533,12 +536,6 @@ pid_t __task_pid_nr_ns(struct task_struc
 }
 EXPORT_SYMBOL(__task_pid_nr_ns);
 
-pid_t task_tgid_nr_ns(struct task_struct *tsk, struct pid_namespace *ns)
-{
-	return pid_nr_ns(task_tgid(tsk), ns);
-}
-EXPORT_SYMBOL(task_tgid_nr_ns);
-
 struct pid_namespace *task_active_pid_ns(struct task_struct *tsk)
 {
 	return ns_of_pid(task_pid(tsk));
author maintainer
#10 lore raw

PATCH 10/10 usb: qmi_wwan: add D-Link DWM-222 device ID

In reply to Greg Kroah-Hartman

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

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

From: Hector Martin <[email protected]>

commit bed9ff165960921303a100228585f2d1691b42eb upstream.

---
 drivers/net/usb/qmi_wwan.c |    1 +
 1 file changed, 1 insertion(+)
drivers/net/usb/qmi_wwan.c +1 -0
@@ -749,6 +749,7 @@ static const struct usb_device_id produc
 	{QMI_FIXED_INTF(0x19d2, 0x1428, 2)},	/* Telewell TW-LTE 4G v2 */
 	{QMI_FIXED_INTF(0x19d2, 0x2002, 4)},	/* ZTE (Vodafone) K3765-Z */
 	{QMI_FIXED_INTF(0x2001, 0x7e19, 4)},	/* D-Link DWM-221 B1 */
+	{QMI_FIXED_INTF(0x2001, 0x7e35, 4)},	/* D-Link DWM-222 */
 	{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)},    /* Sierra Wireless MC7700 */
 	{QMI_FIXED_INTF(0x114f, 0x68a2, 8)},    /* Sierra Wireless MC7750 */
 	{QMI_FIXED_INTF(0x1199, 0x68a2, 8)},	/* Sierra Wireless MC7710 in QMI mode */
#11 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.18.67 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu Aug 24 19:08:42 UTC 2017. Anything received after that time might be too late.

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

Quoted 9 lines
	kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.67-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

#12 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.18.67 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu Aug 24 19:08:42 UTC 2017. Anything received after that time might be too late.

Better late than never. Sorry, I was out of town.

Build results:

	total: 136 pass: 136 fail: 0
Qemu test results:
	total: 111 pass: 111 fail: 0

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

Guenter

author maintainer
#13 lore raw
Quoted 11 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.18.67 release. There are 10 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu Aug 24 19:08:42 UTC 2017. Anything received after that time might be too late.

Better late than never. Sorry, I was out of town.

Not a problem, so was I :)

Quoted 5 lines

Build results:

	total: 136 pass: 136 fail: 0
Qemu test results:
	total: 111 pass: 111 fail: 0

Thanks for the report for all of these.

greg k-h