From: Greg Kroah-Hartman Date: Sun, 24 Jul 2016 23:04:43 +0000 (-0700) Subject: 3.14-stable patches X-Git-Tag: v4.6.5~19 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=618469bb7bfb4c00239be5dc8404f0f9456a89f6;p=thirdparty%2Fkernel%2Fstable-queue.git 3.14-stable patches added patches: base-make-module_create_drivers_dir-race-free.patch hid-elo-kill-not-flush-the-work.patch hid-hiddev-validate-num_values-for-hidiocgusages-hidiocsusages-commands.patch keys-potential-uninitialized-variable.patch kvm-fix-irq-route-entries-exceeding-kvm_max_irq_routes.patch tracing-handle-null-formats-in-hold_module_trace_bprintk_format.patch --- diff --git a/queue-3.14/base-make-module_create_drivers_dir-race-free.patch b/queue-3.14/base-make-module_create_drivers_dir-race-free.patch new file mode 100644 index 00000000000..20c31c67ff0 --- /dev/null +++ b/queue-3.14/base-make-module_create_drivers_dir-race-free.patch @@ -0,0 +1,83 @@ +From 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 Mon Sep 17 00:00:00 2001 +From: Jiri Slaby +Date: Fri, 10 Jun 2016 10:54:32 +0200 +Subject: base: make module_create_drivers_dir race-free + +From: Jiri Slaby + +commit 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 upstream. + +Modules which register drivers via standard path (driver_register) in +parallel can cause a warning: +WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 +sysfs: cannot create duplicate filename '/module/saa7146/drivers' +Modules linked in: hexium_gemini(+) mxb(+) ... +... +Call Trace: +... + [] sysfs_warn_dup+0x62/0x80 + [] sysfs_create_dir_ns+0x77/0x90 + [] kobject_add_internal+0xb4/0x340 + [] kobject_add+0x68/0xb0 + [] kobject_create_and_add+0x31/0x70 + [] module_add_driver+0xc3/0xd0 + [] bus_add_driver+0x154/0x280 + [] driver_register+0x60/0xe0 + [] __pci_register_driver+0x60/0x70 + [] saa7146_register_extension+0x64/0x90 [saa7146] + [] hexium_init_module+0x11/0x1000 [hexium_gemini] +... + +As can be (mostly) seen, driver_register causes this call sequence: + -> bus_add_driver + -> module_add_driver + -> module_create_drivers_dir +The last one creates "drivers" directory in /sys/module/<...>. When +this is done in parallel, the directory is attempted to be created +twice at the same time. + +This can be easily reproduced by loading mxb and hexium_gemini in +parallel: +while :; do + modprobe mxb & + modprobe hexium_gemini + wait + rmmod mxb hexium_gemini saa7146_vv saa7146 +done + +saa7146 calls pci_register_driver for both mxb and hexium_gemini, +which means /sys/module/saa7146/drivers is to be created for both of +them. + +Fix this by a new mutex in module_create_drivers_dir which makes the +test-and-create "drivers" dir atomic. + +I inverted the condition and removed 'return' to avoid multiple +unlocks or a goto. + +Signed-off-by: Jiri Slaby +Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed) +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/base/module.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/drivers/base/module.c ++++ b/drivers/base/module.c +@@ -24,10 +24,12 @@ static char *make_driver_name(struct dev + + static void module_create_drivers_dir(struct module_kobject *mk) + { +- if (!mk || mk->drivers_dir) +- return; ++ static DEFINE_MUTEX(drivers_dir_mutex); + +- mk->drivers_dir = kobject_create_and_add("drivers", &mk->kobj); ++ mutex_lock(&drivers_dir_mutex); ++ if (mk && !mk->drivers_dir) ++ mk->drivers_dir = kobject_create_and_add("drivers", &mk->kobj); ++ mutex_unlock(&drivers_dir_mutex); + } + + void module_add_driver(struct module *mod, struct device_driver *drv) diff --git a/queue-3.14/hid-elo-kill-not-flush-the-work.patch b/queue-3.14/hid-elo-kill-not-flush-the-work.patch new file mode 100644 index 00000000000..773eef00eef --- /dev/null +++ b/queue-3.14/hid-elo-kill-not-flush-the-work.patch @@ -0,0 +1,32 @@ +From ed596a4a88bd161f868ccba078557ee7ede8a6ef Mon Sep 17 00:00:00 2001 +From: Oliver Neukum +Date: Tue, 31 May 2016 14:48:15 +0200 +Subject: HID: elo: kill not flush the work + +From: Oliver Neukum + +commit ed596a4a88bd161f868ccba078557ee7ede8a6ef upstream. + +Flushing a work that reschedules itself is not a sensible operation. It needs +to be killed. Failure to do so leads to a kernel panic in the timer code. + +Signed-off-by: Oliver Neukum +Reviewed-by: Benjamin Tissoires +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/hid-elo.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/hid/hid-elo.c ++++ b/drivers/hid/hid-elo.c +@@ -259,7 +259,7 @@ static void elo_remove(struct hid_device + struct elo_priv *priv = hid_get_drvdata(hdev); + + hid_hw_stop(hdev); +- flush_workqueue(wq); ++ cancel_delayed_work_sync(&priv->work); + kfree(priv); + } + diff --git a/queue-3.14/hid-hiddev-validate-num_values-for-hidiocgusages-hidiocsusages-commands.patch b/queue-3.14/hid-hiddev-validate-num_values-for-hidiocgusages-hidiocsusages-commands.patch new file mode 100644 index 00000000000..69d045d3a41 --- /dev/null +++ b/queue-3.14/hid-hiddev-validate-num_values-for-hidiocgusages-hidiocsusages-commands.patch @@ -0,0 +1,43 @@ +From 93a2001bdfd5376c3dc2158653034c20392d15c5 Mon Sep 17 00:00:00 2001 +From: Scott Bauer +Date: Thu, 23 Jun 2016 08:59:47 -0600 +Subject: HID: hiddev: validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commands + +From: Scott Bauer + +commit 93a2001bdfd5376c3dc2158653034c20392d15c5 upstream. + +This patch validates the num_values parameter from userland during the +HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set +to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter +leading to a heap overflow. + +Signed-off-by: Scott Bauer +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/usbhid/hiddev.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/hid/usbhid/hiddev.c ++++ b/drivers/hid/usbhid/hiddev.c +@@ -516,13 +516,13 @@ static noinline int hiddev_ioctl_usage(s + goto inval; + } else if (uref->usage_index >= field->report_count) + goto inval; +- +- else if ((cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) && +- (uref_multi->num_values > HID_MAX_MULTI_USAGES || +- uref->usage_index + uref_multi->num_values > field->report_count)) +- goto inval; + } + ++ if ((cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) && ++ (uref_multi->num_values > HID_MAX_MULTI_USAGES || ++ uref->usage_index + uref_multi->num_values > field->report_count)) ++ goto inval; ++ + switch (cmd) { + case HIDIOCGUSAGE: + uref->value = field->value[uref->usage_index]; diff --git a/queue-3.14/keys-potential-uninitialized-variable.patch b/queue-3.14/keys-potential-uninitialized-variable.patch new file mode 100644 index 00000000000..bf7e848a6e9 --- /dev/null +++ b/queue-3.14/keys-potential-uninitialized-variable.patch @@ -0,0 +1,91 @@ +From 38327424b40bcebe2de92d07312c89360ac9229a Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Thu, 16 Jun 2016 15:48:57 +0100 +Subject: KEYS: potential uninitialized variable + +From: Dan Carpenter + +commit 38327424b40bcebe2de92d07312c89360ac9229a upstream. + +If __key_link_begin() failed then "edit" would be uninitialized. I've +added a check to fix that. + +This allows a random user to crash the kernel, though it's quite +difficult to achieve. There are three ways it can be done as the user +would have to cause an error to occur in __key_link(): + + (1) Cause the kernel to run out of memory. In practice, this is difficult + to achieve without ENOMEM cropping up elsewhere and aborting the + attempt. + + (2) Revoke the destination keyring between the keyring ID being looked up + and it being tested for revocation. In practice, this is difficult to + time correctly because the KEYCTL_REJECT function can only be used + from the request-key upcall process. Further, users can only make use + of what's in /sbin/request-key.conf, though this does including a + rejection debugging test - which means that the destination keyring + has to be the caller's session keyring in practice. + + (3) Have just enough key quota available to create a key, a new session + keyring for the upcall and a link in the session keyring, but not then + sufficient quota to create a link in the nominated destination keyring + so that it fails with EDQUOT. + +The bug can be triggered using option (3) above using something like the +following: + + echo 80 >/proc/sys/kernel/keys/root_maxbytes + keyctl request2 user debug:fred negate @t + +The above sets the quota to something much lower (80) to make the bug +easier to trigger, but this is dependent on the system. Note also that +the name of the keyring created contains a random number that may be +between 1 and 10 characters in size, so may throw the test off by +changing the amount of quota used. + +Assuming the failure occurs, something like the following will be seen: + + kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h + ------------[ cut here ]------------ + kernel BUG at ../mm/slab.c:2821! + ... + RIP: 0010:[] kfree_debugcheck+0x20/0x25 + RSP: 0018:ffff8804014a7de8 EFLAGS: 00010092 + RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000 + RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300 + RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000 + R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202 + R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001 + ... + Call Trace: + kfree+0xde/0x1bc + assoc_array_cancel_edit+0x1f/0x36 + __key_link_end+0x55/0x63 + key_reject_and_link+0x124/0x155 + keyctl_reject_key+0xb6/0xe0 + keyctl_negate_key+0x10/0x12 + SyS_keyctl+0x9f/0xe7 + do_syscall_64+0x63/0x13a + entry_SYSCALL64_slow_path+0x25/0x25 + +Fixes: f70e2e06196a ('KEYS: Do preallocation for __key_link()') +Signed-off-by: Dan Carpenter +Signed-off-by: David Howells +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + security/keys/key.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/security/keys/key.c ++++ b/security/keys/key.c +@@ -575,7 +575,7 @@ int key_reject_and_link(struct key *key, + + mutex_unlock(&key_construction_mutex); + +- if (keyring) ++ if (keyring && link_ret == 0) + __key_link_end(keyring, &key->index_key, edit); + + /* wake up anyone waiting for a key to be constructed */ diff --git a/queue-3.14/kvm-fix-irq-route-entries-exceeding-kvm_max_irq_routes.patch b/queue-3.14/kvm-fix-irq-route-entries-exceeding-kvm_max_irq_routes.patch new file mode 100644 index 00000000000..984fec75975 --- /dev/null +++ b/queue-3.14/kvm-fix-irq-route-entries-exceeding-kvm_max_irq_routes.patch @@ -0,0 +1,72 @@ +From caf1ff26e1aa178133df68ac3d40815fed2187d9 Mon Sep 17 00:00:00 2001 +From: Xiubo Li +Date: Wed, 15 Jun 2016 18:00:33 +0800 +Subject: kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES + +From: Xiubo Li + +commit caf1ff26e1aa178133df68ac3d40815fed2187d9 upstream. + +These days, we experienced one guest crash with 8 cores and 3 disks, +with qemu error logs as bellow: + +qemu-system-x86_64: /build/qemu-2.0.0/kvm-all.c:984: +kvm_irqchip_commit_routes: Assertion `ret == 0' failed. + +And then we found one patch(bdf026317d) in qemu tree, which said +could fix this bug. + +Execute the following script will reproduce the BUG quickly: + +irq_affinity.sh +======================================================================== + +vda_irq_num=25 +vdb_irq_num=27 +while [ 1 ] +do + for irq in {1,2,4,8,10,20,40,80} + do + echo $irq > /proc/irq/$vda_irq_num/smp_affinity + echo $irq > /proc/irq/$vdb_irq_num/smp_affinity + dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct + dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct + done +done +======================================================================== + +The following qemu log is added in the qemu code and is displayed when +this bug reproduced: + +kvm_irqchip_commit_routes: max gsi: 1008, nr_allocated_irq_routes: 1024, +irq_routes->nr: 1024, gsi_count: 1024. + +That's to say when irq_routes->nr == 1024, there are 1024 routing entries, +but in the kernel code when routes->nr >= 1024, will just return -EINVAL; + +The nr is the number of the routing entries which is in of +[1 ~ KVM_MAX_IRQ_ROUTES], not the index in [0 ~ KVM_MAX_IRQ_ROUTES - 1]. + +This patch fix the BUG above. + +Signed-off-by: Xiubo Li +Signed-off-by: Wei Tang +Signed-off-by: Zhang Zhuoyu +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + virt/kvm/kvm_main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -2455,7 +2455,7 @@ static long kvm_vm_ioctl(struct file *fi + if (copy_from_user(&routing, argp, sizeof(routing))) + goto out; + r = -EINVAL; +- if (routing.nr >= KVM_MAX_IRQ_ROUTES) ++ if (routing.nr > KVM_MAX_IRQ_ROUTES) + goto out; + if (routing.flags) + goto out; diff --git a/queue-3.14/series b/queue-3.14/series index 955fd5cfc0f..c5e92f1be93 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -25,3 +25,9 @@ nfsd-check-permissions-when-setting-acls.patch signal-remove-warning-about-using-si_tkill-in-rt_sigqueueinfo.patch mips-kvm-fix-modular-kvm-under-qemu.patch cdc_ncm-workaround-for-em7455-silent-data-interface.patch +keys-potential-uninitialized-variable.patch +kvm-fix-irq-route-entries-exceeding-kvm_max_irq_routes.patch +hid-elo-kill-not-flush-the-work.patch +hid-hiddev-validate-num_values-for-hidiocgusages-hidiocsusages-commands.patch +tracing-handle-null-formats-in-hold_module_trace_bprintk_format.patch +base-make-module_create_drivers_dir-race-free.patch diff --git a/queue-3.14/tracing-handle-null-formats-in-hold_module_trace_bprintk_format.patch b/queue-3.14/tracing-handle-null-formats-in-hold_module_trace_bprintk_format.patch new file mode 100644 index 00000000000..e49ea732a16 --- /dev/null +++ b/queue-3.14/tracing-handle-null-formats-in-hold_module_trace_bprintk_format.patch @@ -0,0 +1,61 @@ +From 70c8217acd4383e069fe1898bbad36ea4fcdbdcc Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Red Hat)" +Date: Fri, 17 Jun 2016 16:10:42 -0400 +Subject: tracing: Handle NULL formats in hold_module_trace_bprintk_format() + +From: Steven Rostedt (Red Hat) + +commit 70c8217acd4383e069fe1898bbad36ea4fcdbdcc upstream. + +If a task uses a non constant string for the format parameter in +trace_printk(), then the trace_printk_fmt variable is set to NULL. This +variable is then saved in the __trace_printk_fmt section. + +The function hold_module_trace_bprintk_format() checks to see if duplicate +formats are used by modules, and reuses them if so (saves them to the list +if it is new). But this function calls lookup_format() that does a strcmp() +to the value (which is now NULL) and can cause a kernel oops. + +This wasn't an issue till 3debb0a9ddb ("tracing: Fix trace_printk() to print +when not using bprintk()") which added "__used" to the trace_printk_fmt +variable, and before that, the kernel simply optimized it out (no NULL value +was saved). + +The fix is simply to handle the NULL pointer in lookup_format() and have the +caller ignore the value if it was NULL. + +Link: http://lkml.kernel.org/r/1464769870-18344-1-git-send-email-zhengjun.xing@intel.com + +Reported-by: xingzhen +Acked-by: Namhyung Kim +Fixes: 3debb0a9ddb ("tracing: Fix trace_printk() to print when not using bprintk()") +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace_printk.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/kernel/trace/trace_printk.c ++++ b/kernel/trace/trace_printk.c +@@ -38,6 +38,10 @@ struct trace_bprintk_fmt { + static inline struct trace_bprintk_fmt *lookup_format(const char *fmt) + { + struct trace_bprintk_fmt *pos; ++ ++ if (!fmt) ++ return ERR_PTR(-EINVAL); ++ + list_for_each_entry(pos, &trace_bprintk_fmt_list, list) { + if (!strcmp(pos->fmt, fmt)) + return pos; +@@ -59,7 +63,8 @@ void hold_module_trace_bprintk_format(co + for (iter = start; iter < end; iter++) { + struct trace_bprintk_fmt *tb_fmt = lookup_format(*iter); + if (tb_fmt) { +- *iter = tb_fmt->fmt; ++ if (!IS_ERR(tb_fmt)) ++ *iter = tb_fmt->fmt; + continue; + } +