--- /dev/null
+From 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Fri, 10 Jun 2016 10:54:32 +0200
+Subject: base: make module_create_drivers_dir race-free
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+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:
+...
+ [<ffffffff812e63a2>] sysfs_warn_dup+0x62/0x80
+ [<ffffffff812e6487>] sysfs_create_dir_ns+0x77/0x90
+ [<ffffffff8140f2c4>] kobject_add_internal+0xb4/0x340
+ [<ffffffff8140f5b8>] kobject_add+0x68/0xb0
+ [<ffffffff8140f631>] kobject_create_and_add+0x31/0x70
+ [<ffffffff8157a703>] module_add_driver+0xc3/0xd0
+ [<ffffffff8155e5d4>] bus_add_driver+0x154/0x280
+ [<ffffffff815604c0>] driver_register+0x60/0xe0
+ [<ffffffff8145bed0>] __pci_register_driver+0x60/0x70
+ [<ffffffffa0273e14>] saa7146_register_extension+0x64/0x90 [saa7146]
+ [<ffffffffa0033011>] 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 <jslaby@suse.cz>
+Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed)
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From ed596a4a88bd161f868ccba078557ee7ede8a6ef Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+Date: Tue, 31 May 2016 14:48:15 +0200
+Subject: HID: elo: kill not flush the work
+
+From: Oliver Neukum <oneukum@suse.com>
+
+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 <ONeukum@suse.com>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+
--- /dev/null
+From 93a2001bdfd5376c3dc2158653034c20392d15c5 Mon Sep 17 00:00:00 2001
+From: Scott Bauer <sbauer@plzdonthack.me>
+Date: Thu, 23 Jun 2016 08:59:47 -0600
+Subject: HID: hiddev: validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commands
+
+From: Scott Bauer <sbauer@plzdonthack.me>
+
+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 <sbauer@plzdonthack.me>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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];
--- /dev/null
+From 38327424b40bcebe2de92d07312c89360ac9229a Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Thu, 16 Jun 2016 15:48:57 +0100
+Subject: KEYS: potential uninitialized variable
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+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:[<ffffffff811600f9>] 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 <dan.carpenter@oracle.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
--- /dev/null
+From caf1ff26e1aa178133df68ac3d40815fed2187d9 Mon Sep 17 00:00:00 2001
+From: Xiubo Li <lixiubo@cmss.chinamobile.com>
+Date: Wed, 15 Jun 2016 18:00:33 +0800
+Subject: kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES
+
+From: Xiubo Li <lixiubo@cmss.chinamobile.com>
+
+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 <lixiubo@cmss.chinamobile.com>
+Signed-off-by: Wei Tang <tangwei@cmss.chinamobile.com>
+Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From 70c8217acd4383e069fe1898bbad36ea4fcdbdcc Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
+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) <rostedt@goodmis.org>
+
+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 <zhengjun.xing@intel.com>
+Acked-by: Namhyung Kim <namhyung@kernel.org>
+Fixes: 3debb0a9ddb ("tracing: Fix trace_printk() to print when not using bprintk()")
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
