--- /dev/null
+From bf563b01c2895a4bfd1a29cc5abc67fe706ecffd Mon Sep 17 00:00:00 2001
+From: Nicolai Stange <nstange@suse.de>
+Date: Mon, 11 Sep 2017 09:45:42 +0200
+Subject: driver core: platform: Don't read past the end of "driver_override" buffer
+
+From: Nicolai Stange <nstange@suse.de>
+
+commit bf563b01c2895a4bfd1a29cc5abc67fe706ecffd upstream.
+
+When printing the driver_override parameter when it is 4095 and 4094 bytes
+long, the printing code would access invalid memory because we need count+1
+bytes for printing.
+
+Reject driver_override values of these lengths in driver_override_store().
+
+This is in close analogy to commit 4efe874aace5 ("PCI: Don't read past the
+end of sysfs "driver_override" buffer") from Sasha Levin.
+
+Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'")
+Signed-off-by: Nicolai Stange <nstange@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/base/platform.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/base/platform.c
++++ b/drivers/base/platform.c
+@@ -809,7 +809,8 @@ static ssize_t driver_override_store(str
+ struct platform_device *pdev = to_platform_device(dev);
+ char *driver_override, *old, *cp;
+
+- if (count > PATH_MAX)
++ /* We need to keep extra room for a newline */
++ if (count >= (PAGE_SIZE - 1))
+ return -EINVAL;
+
+ driver_override = kstrndup(buf, count, GFP_KERNEL);
--- /dev/null
+From 549e658a0919e355a2b2144dc380b3729bef7f3e Mon Sep 17 00:00:00 2001
+From: Olaf Hering <olaf@aepfle.de>
+Date: Thu, 21 Sep 2017 23:41:48 -0700
+Subject: Drivers: hv: fcopy: restore correct transfer length
+
+From: Olaf Hering <olaf@aepfle.de>
+
+commit 549e658a0919e355a2b2144dc380b3729bef7f3e upstream.
+
+Till recently the expected length of bytes read by the
+daemon did depend on the context. It was either hv_start_fcopy or
+hv_do_fcopy. The daemon had a buffer size of two pages, which was much
+larger than needed.
+
+Now the expected length of bytes read by the
+daemon changed slightly. For START_FILE_COPY it is still the size of
+hv_start_fcopy. But for WRITE_TO_FILE and the other operations it is as
+large as the buffer that arrived via vmbus. In case of WRITE_TO_FILE
+that is slightly larger than a struct hv_do_fcopy. Since the buffer in
+the daemon was still larger everything was fine.
+
+Currently, the daemon reads only what is actually needed.
+The new buffer layout is as large as a struct hv_do_fcopy, for the
+WRITE_TO_FILE operation. Since the kernel expects a slightly larger
+size, hvt_op_read will return -EINVAL because the daemon will read
+slightly less than expected. Address this by restoring the expected
+buffer size in case of WRITE_TO_FILE.
+
+Fixes: 'c7e490fc23eb ("Drivers: hv: fcopy: convert to hv_utils_transport")'
+Fixes: '3f2baa8a7d2e ("Tools: hv: update buffer handling in hv_fcopy_daemon")'
+
+Signed-off-by: Olaf Hering <olaf@aepfle.de>
+Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hv/hv_fcopy.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/hv/hv_fcopy.c
++++ b/drivers/hv/hv_fcopy.c
+@@ -155,6 +155,10 @@ static void fcopy_send_data(struct work_
+ out_src = smsg_out;
+ break;
+
++ case WRITE_TO_FILE:
++ out_src = fcopy_transaction.fcopy_msg;
++ out_len = sizeof(struct hv_do_fcopy);
++ break;
+ default:
+ out_src = fcopy_transaction.fcopy_msg;
+ out_len = fcopy_transaction.recv_len;
--- /dev/null
+From 2b0b8499ae75df91455bbeb7491d45affc384fb0 Mon Sep 17 00:00:00 2001
+From: Shu Wang <shuwang@redhat.com>
+Date: Tue, 12 Sep 2017 10:14:54 +0800
+Subject: ftrace: Fix kmemleak in unregister_ftrace_graph
+
+From: Shu Wang <shuwang@redhat.com>
+
+commit 2b0b8499ae75df91455bbeb7491d45affc384fb0 upstream.
+
+The trampoline allocated by function tracer was overwriten by function_graph
+tracer, and caused a memory leak. The save_global_trampoline should have
+saved the previous trampoline in register_ftrace_graph() and restored it in
+unregister_ftrace_graph(). But as it is implemented, save_global_trampoline was
+only used in unregister_ftrace_graph as default value 0, and it overwrote the
+previous trampoline's value. Causing the previous allocated trampoline to be
+lost.
+
+kmmeleak backtrace:
+ kmemleak_vmalloc+0x77/0xc0
+ __vmalloc_node_range+0x1b5/0x2c0
+ module_alloc+0x7c/0xd0
+ arch_ftrace_update_trampoline+0xb5/0x290
+ ftrace_startup+0x78/0x210
+ register_ftrace_function+0x8b/0xd0
+ function_trace_init+0x4f/0x80
+ tracing_set_tracer+0xe6/0x170
+ tracing_set_trace_write+0x90/0xd0
+ __vfs_write+0x37/0x170
+ vfs_write+0xb2/0x1b0
+ SyS_write+0x55/0xc0
+ do_syscall_64+0x67/0x180
+ return_from_SYSCALL_64+0x0/0x6a
+
+[
+ Looking further into this, I found that this was left over from when the
+ function and function graph tracers shared the same ftrace_ops. But in
+ commit 5f151b2401 ("ftrace: Fix function_profiler and function tracer
+ together"), the two were separated, and the save_global_trampoline no
+ longer was necessary (and it may have been broken back then too).
+ -- Steven Rostedt
+]
+
+Link: http://lkml.kernel.org/r/20170912021454.5976-1-shuwang@redhat.com
+
+Fixes: 5f151b2401 ("ftrace: Fix function_profiler and function tracer together")
+Signed-off-by: Shu Wang <shuwang@redhat.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/ftrace.c | 14 --------------
+ 1 file changed, 14 deletions(-)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -4315,9 +4315,6 @@ static char ftrace_graph_buf[FTRACE_FILT
+ static char ftrace_graph_notrace_buf[FTRACE_FILTER_SIZE] __initdata;
+ static int ftrace_set_func(unsigned long *array, int *idx, int size, char *buffer);
+
+-static unsigned long save_global_trampoline;
+-static unsigned long save_global_flags;
+-
+ static int __init set_graph_function(char *str)
+ {
+ strlcpy(ftrace_graph_buf, str, FTRACE_FILTER_SIZE);
+@@ -5907,17 +5904,6 @@ void unregister_ftrace_graph(void)
+ unregister_pm_notifier(&ftrace_suspend_notifier);
+ unregister_trace_sched_switch(ftrace_graph_probe_sched_switch, NULL);
+
+-#ifdef CONFIG_DYNAMIC_FTRACE
+- /*
+- * Function graph does not allocate the trampoline, but
+- * other global_ops do. We need to reset the ALLOC_TRAMP flag
+- * if one was used.
+- */
+- global_ops.trampoline = save_global_trampoline;
+- if (save_global_flags & FTRACE_OPS_FL_ALLOC_TRAMP)
+- global_ops.flags |= FTRACE_OPS_FL_ALLOC_TRAMP;
+-#endif
+-
+ out:
+ mutex_unlock(&ftrace_lock);
+ }
--- /dev/null
+From 8320caeeffdefec3b58b9d4a7ed8e1079492fe7b Mon Sep 17 00:00:00 2001
+From: Adrian Salido <salidoa@google.com>
+Date: Fri, 8 Sep 2017 10:55:27 -0700
+Subject: HID: i2c-hid: allocate hid buffers for real worst case
+
+From: Adrian Salido <salidoa@google.com>
+
+commit 8320caeeffdefec3b58b9d4a7ed8e1079492fe7b upstream.
+
+The buffer allocation is not currently accounting for an extra byte for
+the report id. This can cause an out of bounds access in function
+i2c_hid_set_or_send_report() with reportID > 15.
+
+Signed-off-by: Adrian Salido <salidoa@google.com>
+Reviewed-by: Benson Leung <bleung@chromium.org>
+Signed-off-by: Guenter Roeck <groeck@chromium.org>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/i2c-hid/i2c-hid.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/hid/i2c-hid/i2c-hid.c
++++ b/drivers/hid/i2c-hid/i2c-hid.c
+@@ -540,7 +540,8 @@ static int i2c_hid_alloc_buffers(struct
+ {
+ /* the worst case is computed from the set_report command with a
+ * reportID > 15 and the maximum report length */
+- int args_len = sizeof(__u8) + /* optional ReportID byte */
++ int args_len = sizeof(__u8) + /* ReportID */
++ sizeof(__u8) + /* optional ReportID byte */
+ sizeof(__u16) + /* data register */
+ sizeof(__u16) + /* size of the report */
+ report_size; /* report */
--- /dev/null
+From 920ce7c33db25cf4acb4ade3ae8c93bd23dfd730 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Tue, 19 Sep 2017 18:47:41 +0300
+Subject: intel_th: pci: Add Cedar Fork PCH support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 920ce7c33db25cf4acb4ade3ae8c93bd23dfd730 upstream.
+
+This adds Intel(R) Trace Hub PCI ID for Cedar Fork PCH.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwtracing/intel_th/pci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -82,6 +82,11 @@ static const struct pci_device_id intel_
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9da6),
+ .driver_data = (kernel_ulong_t)0,
+ },
++ {
++ /* Cedar Fork PCH */
++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x18e1),
++ .driver_data = (kernel_ulong_t)&intel_th_2x,
++ },
+ { 0 },
+ };
+
--- /dev/null
+From 24600840c74112ad04a9ddd99d7d7f731dcaa1cb Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Tue, 19 Sep 2017 18:47:42 +0300
+Subject: intel_th: pci: Add Lewisburg PCH support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit 24600840c74112ad04a9ddd99d7d7f731dcaa1cb upstream.
+
+This adds Intel(R) Trace Hub PCI ID for Lewisburg PCH.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwtracing/intel_th/pci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/hwtracing/intel_th/pci.c
++++ b/drivers/hwtracing/intel_th/pci.c
+@@ -83,6 +83,11 @@ static const struct pci_device_id intel_
+ .driver_data = (kernel_ulong_t)0,
+ },
+ {
++ /* Lewisburg PCH */
++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xa1a6),
++ .driver_data = (kernel_ulong_t)0,
++ },
++ {
+ /* Cedar Fork PCH */
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x18e1),
+ .driver_data = (kernel_ulong_t)&intel_th_2x,
lsm-fix-smack_inode_removexattr-and-xattr_getsecurity-memleak.patch
alsa-compress-remove-unused-variable.patch
alsa-usx2y-suppress-kernel-warning-at-page-allocation-failures.patch
+intel_th-pci-add-cedar-fork-pch-support.patch
+intel_th-pci-add-lewisburg-pch-support.patch
+driver-core-platform-don-t-read-past-the-end-of-driver_override-buffer.patch
+drivers-hv-fcopy-restore-correct-transfer-length.patch
+stm-class-fix-a-use-after-free.patch
+ftrace-fix-kmemleak-in-unregister_ftrace_graph.patch
+hid-i2c-hid-allocate-hid-buffers-for-real-worst-case.patch
usb-uas-fix-bug-in-handling-of-alternate-settings.patch
usb-core-harden-cdc_parse_cdc_header.patch
usb-increase-quirk-delay-for-usb-devices.patch
--- /dev/null
+From fd085bb1766d6a598f53af2308374a546a49775a Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Tue, 19 Sep 2017 18:47:40 +0300
+Subject: stm class: Fix a use-after-free
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit fd085bb1766d6a598f53af2308374a546a49775a upstream.
+
+For reasons unknown, the stm_source removal path uses device_destroy()
+to kill the underlying device object. Because device_destroy() uses
+devt to look for the device to destroy and the fact that stm_source
+devices don't have one (or all have the same one), it just picks the
+first device in the class, which may well be the wrong one.
+
+That is, loading stm_console and stm_heartbeat and then removing both
+will die in dereferencing a freed object.
+
+Since this should have been device_unregister() in the first place,
+use it instead of device_destroy().
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Fixes: 7bd1d4093c2 ("stm class: Introduce an abstraction for System Trace Module devices")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwtracing/stm/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hwtracing/stm/core.c
++++ b/drivers/hwtracing/stm/core.c
+@@ -952,7 +952,7 @@ void stm_source_unregister_device(struct
+
+ stm_source_link_drop(src);
+
+- device_destroy(&stm_source_class, src->dev.devt);
++ device_unregister(&src->dev);
+ }
+ EXPORT_SYMBOL_GPL(stm_source_unregister_device);
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
