From: Greg Kroah-Hartman Date: Tue, 10 Oct 2017 15:13:35 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v3.18.75~14 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=28cd8e7b92f1842330ef2c0974a73381aacf1f5b;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: driver-core-platform-don-t-read-past-the-end-of-driver_override-buffer.patch drivers-hv-fcopy-restore-correct-transfer-length.patch ftrace-fix-kmemleak-in-unregister_ftrace_graph.patch hid-i2c-hid-allocate-hid-buffers-for-real-worst-case.patch hid-wacom-always-increment-hdev-refcount-within-wacom_get_hdev_data.patch hid-wacom-bits-shifted-too-much-for-9th-and-10th-buttons.patch hid-wacom-leds-don-t-try-to-control-the-ekr-s-read-only-leds.patch intel_th-pci-add-cedar-fork-pch-support.patch intel_th-pci-add-lewisburg-pch-support.patch netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch rocker-fix-rocker_tlv_put_-functions-for-kasan.patch stm-class-fix-a-use-after-free.patch --- diff --git a/queue-4.9/driver-core-platform-don-t-read-past-the-end-of-driver_override-buffer.patch b/queue-4.9/driver-core-platform-don-t-read-past-the-end-of-driver_override-buffer.patch new file mode 100644 index 00000000000..e0c2315211f --- /dev/null +++ b/queue-4.9/driver-core-platform-don-t-read-past-the-end-of-driver_override-buffer.patch @@ -0,0 +1,38 @@ +From bf563b01c2895a4bfd1a29cc5abc67fe706ecffd Mon Sep 17 00:00:00 2001 +From: Nicolai Stange +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 + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/base/platform.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/base/platform.c ++++ b/drivers/base/platform.c +@@ -858,7 +858,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); diff --git a/queue-4.9/drivers-hv-fcopy-restore-correct-transfer-length.patch b/queue-4.9/drivers-hv-fcopy-restore-correct-transfer-length.patch new file mode 100644 index 00000000000..4de0ba91551 --- /dev/null +++ b/queue-4.9/drivers-hv-fcopy-restore-correct-transfer-length.patch @@ -0,0 +1,53 @@ +From 549e658a0919e355a2b2144dc380b3729bef7f3e Mon Sep 17 00:00:00 2001 +From: Olaf Hering +Date: Thu, 21 Sep 2017 23:41:48 -0700 +Subject: Drivers: hv: fcopy: restore correct transfer length + +From: Olaf Hering + +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 +Signed-off-by: K. Y. Srinivasan +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hv/hv_fcopy.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/hv/hv_fcopy.c ++++ b/drivers/hv/hv_fcopy.c +@@ -161,6 +161,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; diff --git a/queue-4.9/ftrace-fix-kmemleak-in-unregister_ftrace_graph.patch b/queue-4.9/ftrace-fix-kmemleak-in-unregister_ftrace_graph.patch new file mode 100644 index 00000000000..bd81fa6ce83 --- /dev/null +++ b/queue-4.9/ftrace-fix-kmemleak-in-unregister_ftrace_graph.patch @@ -0,0 +1,83 @@ +From 2b0b8499ae75df91455bbeb7491d45affc384fb0 Mon Sep 17 00:00:00 2001 +From: Shu Wang +Date: Tue, 12 Sep 2017 10:14:54 +0800 +Subject: ftrace: Fix kmemleak in unregister_ftrace_graph + +From: Shu Wang + +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 +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/ftrace.c | 14 -------------- + 1 file changed, 14 deletions(-) + +--- a/kernel/trace/ftrace.c ++++ b/kernel/trace/ftrace.c +@@ -4381,9 +4381,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); +@@ -5981,17 +5978,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); + } diff --git a/queue-4.9/hid-i2c-hid-allocate-hid-buffers-for-real-worst-case.patch b/queue-4.9/hid-i2c-hid-allocate-hid-buffers-for-real-worst-case.patch new file mode 100644 index 00000000000..7769dc6cb31 --- /dev/null +++ b/queue-4.9/hid-i2c-hid-allocate-hid-buffers-for-real-worst-case.patch @@ -0,0 +1,36 @@ +From 8320caeeffdefec3b58b9d4a7ed8e1079492fe7b Mon Sep 17 00:00:00 2001 +From: Adrian Salido +Date: Fri, 8 Sep 2017 10:55:27 -0700 +Subject: HID: i2c-hid: allocate hid buffers for real worst case + +From: Adrian Salido + +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 +Reviewed-by: Benson Leung +Signed-off-by: Guenter Roeck +Signed-off-by: Dmitry Torokhov +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -604,7 +604,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 */ diff --git a/queue-4.9/hid-wacom-always-increment-hdev-refcount-within-wacom_get_hdev_data.patch b/queue-4.9/hid-wacom-always-increment-hdev-refcount-within-wacom_get_hdev_data.patch new file mode 100644 index 00000000000..2197c44863d --- /dev/null +++ b/queue-4.9/hid-wacom-always-increment-hdev-refcount-within-wacom_get_hdev_data.patch @@ -0,0 +1,45 @@ +From 2a5e597c6bb1b873e473e5f57147e9e5d2755430 Mon Sep 17 00:00:00 2001 +From: Jason Gerecke +Date: Mon, 18 Sep 2017 09:27:42 -0700 +Subject: HID: wacom: Always increment hdev refcount within wacom_get_hdev_data + +From: Jason Gerecke + +commit 2a5e597c6bb1b873e473e5f57147e9e5d2755430 upstream. + +The wacom_get_hdev_data function is used to find and return a reference to +the "other half" of a Wacom device (i.e., the touch device associated with +a pen, or vice-versa). To ensure these references are properly accounted +for, the function is supposed to automatically increment the refcount before +returning. This was not done, however, for devices which have pen & touch +on different interfaces of the same USB device. This can lead to a WARNING +("refcount_t: underflow; use-after-free") when removing the module or device +as we call kref_put() more times than kref_get(). Triggering an "actual" use- +after-free would be difficult since both devices will disappear nearly- +simultaneously. To silence this warning and prevent the potential error, we +need to increment the refcount for all cases within wacom_get_hdev_data. + +Fixes: 41372d5d40 ("HID: wacom: Augment 'oVid' and 'oPid' with heuristics for HID_GENERIC") +Signed-off-by: Jason Gerecke +Reviewed-by: Ping Cheng +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/wacom_sys.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/hid/wacom_sys.c ++++ b/drivers/hid/wacom_sys.c +@@ -611,8 +611,10 @@ static struct wacom_hdev_data *wacom_get + + /* Try to find an already-probed interface from the same device */ + list_for_each_entry(data, &wacom_udev_list, list) { +- if (compare_device_paths(hdev, data->dev, '/')) ++ if (compare_device_paths(hdev, data->dev, '/')) { ++ kref_get(&data->kref); + return data; ++ } + } + + /* Fallback to finding devices that appear to be "siblings" */ diff --git a/queue-4.9/hid-wacom-bits-shifted-too-much-for-9th-and-10th-buttons.patch b/queue-4.9/hid-wacom-bits-shifted-too-much-for-9th-and-10th-buttons.patch new file mode 100644 index 00000000000..ae615e5881b --- /dev/null +++ b/queue-4.9/hid-wacom-bits-shifted-too-much-for-9th-and-10th-buttons.patch @@ -0,0 +1,37 @@ +From ce06760ba46b66dae50f2519ae76bd15e89b5710 Mon Sep 17 00:00:00 2001 +From: Ping Cheng +Date: Thu, 31 Aug 2017 15:50:03 -0700 +Subject: HID: wacom: bits shifted too much for 9th and 10th buttons + +From: Ping Cheng + +commit ce06760ba46b66dae50f2519ae76bd15e89b5710 upstream. + +Cintiq 12 has 10 expresskey buttons. The bit shift for the last +two buttons were off by 5. + +Fixes: c7f0522 ("HID: wacom: Slim down wacom_intuos_pad processing") + +Signed-off-by: Ping Cheng +Tested-by: Matthieu Robin +Signed-off-by: Jiri Kosina +Cc: Jason Gerecke +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/wacom_wac.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/hid/wacom_wac.c ++++ b/drivers/hid/wacom_wac.c +@@ -559,8 +559,8 @@ static int wacom_intuos_pad(struct wacom + keys = data[9] & 0x07; + } + } else { +- buttons = ((data[6] & 0x10) << 10) | +- ((data[5] & 0x10) << 9) | ++ buttons = ((data[6] & 0x10) << 5) | ++ ((data[5] & 0x10) << 4) | + ((data[6] & 0x0F) << 4) | + (data[5] & 0x0F); + } diff --git a/queue-4.9/hid-wacom-leds-don-t-try-to-control-the-ekr-s-read-only-leds.patch b/queue-4.9/hid-wacom-leds-don-t-try-to-control-the-ekr-s-read-only-leds.patch new file mode 100644 index 00000000000..6ceebf4918d --- /dev/null +++ b/queue-4.9/hid-wacom-leds-don-t-try-to-control-the-ekr-s-read-only-leds.patch @@ -0,0 +1,38 @@ +From 74aebed6dc13425233f2224668353cff7a112776 Mon Sep 17 00:00:00 2001 +From: Aaron Armstrong Skomra +Date: Mon, 28 Aug 2017 14:15:39 -0700 +Subject: HID: wacom: leds: Don't try to control the EKR's read-only LEDs + +From: Aaron Armstrong Skomra + +commit 74aebed6dc13425233f2224668353cff7a112776 upstream. + +Commit a50aac7193f1 introduces 'led.groups' and adds EKR support +for these groups. However, unlike the other devices with LEDs, +the EKR's LEDs are read-only and we shouldn't attempt to control +them in wacom_led_control(). + +See bug: https://sourceforge.net/p/linuxwacom/bugs/342/ + +Fixes: a50aac7193f1 ("HID: wacom: leds: dynamically allocate LED groups") +Signed-off-by: Aaron Armstrong Skomra +Reviewed-by: Jason Gerecke +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hid/wacom_sys.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/hid/wacom_sys.c ++++ b/drivers/hid/wacom_sys.c +@@ -712,6 +712,9 @@ static int wacom_led_control(struct waco + if (!wacom->led.groups) + return -ENOTSUPP; + ++ if (wacom->wacom_wac.features.type == REMOTE) ++ return -ENOTSUPP; ++ + if (wacom->wacom_wac.pid) { /* wireless connected */ + report_id = WAC_CMD_WL_LED_CONTROL; + buf_size = 13; diff --git a/queue-4.9/intel_th-pci-add-cedar-fork-pch-support.patch b/queue-4.9/intel_th-pci-add-cedar-fork-pch-support.patch new file mode 100644 index 00000000000..0d1605c7605 --- /dev/null +++ b/queue-4.9/intel_th-pci-add-cedar-fork-pch-support.patch @@ -0,0 +1,32 @@ +From 920ce7c33db25cf4acb4ade3ae8c93bd23dfd730 Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Tue, 19 Sep 2017 18:47:41 +0300 +Subject: intel_th: pci: Add Cedar Fork PCH support + +From: Alexander Shishkin + +commit 920ce7c33db25cf4acb4ade3ae8c93bd23dfd730 upstream. + +This adds Intel(R) Trace Hub PCI ID for Cedar Fork PCH. + +Signed-off-by: Alexander Shishkin +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -95,6 +95,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 }, + }; + diff --git a/queue-4.9/intel_th-pci-add-lewisburg-pch-support.patch b/queue-4.9/intel_th-pci-add-lewisburg-pch-support.patch new file mode 100644 index 00000000000..29c4cac1c9a --- /dev/null +++ b/queue-4.9/intel_th-pci-add-lewisburg-pch-support.patch @@ -0,0 +1,32 @@ +From 24600840c74112ad04a9ddd99d7d7f731dcaa1cb Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Tue, 19 Sep 2017 18:47:42 +0300 +Subject: intel_th: pci: Add Lewisburg PCH support + +From: Alexander Shishkin + +commit 24600840c74112ad04a9ddd99d7d7f731dcaa1cb upstream. + +This adds Intel(R) Trace Hub PCI ID for Lewisburg PCH. + +Signed-off-by: Alexander Shishkin +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -96,6 +96,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, diff --git a/queue-4.9/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch b/queue-4.9/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch new file mode 100644 index 00000000000..0afb46efc53 --- /dev/null +++ b/queue-4.9/netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch @@ -0,0 +1,238 @@ +From b4391db42308c9940944b5d7be5ca4b78fb88dd0 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 22 Sep 2017 23:29:19 +0200 +Subject: netlink: fix nla_put_{u8,u16,u32} for KASAN + +From: Arnd Bergmann + +commit b4391db42308c9940944b5d7be5ca4b78fb88dd0 upstream. + +When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large +stack frames in some functions. This goes unnoticed normally because +CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit +3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with +KASAN=y"). + +The kernelci.org build bot however has the warning enabled and that led +me to investigate it a little further, as every build produces these warnings: + +net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] +net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is larger than 2048 bytes [-Wframe-larger-than=] +net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] +net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] + +Most of this problem is now solved in gcc-8, which can consolidate +the stack slots for the inline function arguments. On older compilers +we can add a workaround by declaring a local variable in each function +to pass the inline function argument. + +Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 +Signed-off-by: Arnd Bergmann +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + include/net/netlink.h | 73 +++++++++++++++++++++++++++++++++++++------------- + 1 file changed, 55 insertions(+), 18 deletions(-) + +--- a/include/net/netlink.h ++++ b/include/net/netlink.h +@@ -756,7 +756,10 @@ static inline int nla_parse_nested(struc + */ + static inline int nla_put_u8(struct sk_buff *skb, int attrtype, u8 value) + { +- return nla_put(skb, attrtype, sizeof(u8), &value); ++ /* temporary variables to work around GCC PR81715 with asan-stack=1 */ ++ u8 tmp = value; ++ ++ return nla_put(skb, attrtype, sizeof(u8), &tmp); + } + + /** +@@ -767,7 +770,9 @@ static inline int nla_put_u8(struct sk_b + */ + static inline int nla_put_u16(struct sk_buff *skb, int attrtype, u16 value) + { +- return nla_put(skb, attrtype, sizeof(u16), &value); ++ u16 tmp = value; ++ ++ return nla_put(skb, attrtype, sizeof(u16), &tmp); + } + + /** +@@ -778,7 +783,9 @@ static inline int nla_put_u16(struct sk_ + */ + static inline int nla_put_be16(struct sk_buff *skb, int attrtype, __be16 value) + { +- return nla_put(skb, attrtype, sizeof(__be16), &value); ++ __be16 tmp = value; ++ ++ return nla_put(skb, attrtype, sizeof(__be16), &tmp); + } + + /** +@@ -789,7 +796,9 @@ static inline int nla_put_be16(struct sk + */ + static inline int nla_put_net16(struct sk_buff *skb, int attrtype, __be16 value) + { +- return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, value); ++ __be16 tmp = value; ++ ++ return nla_put_be16(skb, attrtype | NLA_F_NET_BYTEORDER, tmp); + } + + /** +@@ -800,7 +809,9 @@ static inline int nla_put_net16(struct s + */ + static inline int nla_put_le16(struct sk_buff *skb, int attrtype, __le16 value) + { +- return nla_put(skb, attrtype, sizeof(__le16), &value); ++ __le16 tmp = value; ++ ++ return nla_put(skb, attrtype, sizeof(__le16), &tmp); + } + + /** +@@ -811,7 +822,9 @@ static inline int nla_put_le16(struct sk + */ + static inline int nla_put_u32(struct sk_buff *skb, int attrtype, u32 value) + { +- return nla_put(skb, attrtype, sizeof(u32), &value); ++ u32 tmp = value; ++ ++ return nla_put(skb, attrtype, sizeof(u32), &tmp); + } + + /** +@@ -822,7 +835,9 @@ static inline int nla_put_u32(struct sk_ + */ + static inline int nla_put_be32(struct sk_buff *skb, int attrtype, __be32 value) + { +- return nla_put(skb, attrtype, sizeof(__be32), &value); ++ __be32 tmp = value; ++ ++ return nla_put(skb, attrtype, sizeof(__be32), &tmp); + } + + /** +@@ -833,7 +848,9 @@ static inline int nla_put_be32(struct sk + */ + static inline int nla_put_net32(struct sk_buff *skb, int attrtype, __be32 value) + { +- return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, value); ++ __be32 tmp = value; ++ ++ return nla_put_be32(skb, attrtype | NLA_F_NET_BYTEORDER, tmp); + } + + /** +@@ -844,7 +861,9 @@ static inline int nla_put_net32(struct s + */ + static inline int nla_put_le32(struct sk_buff *skb, int attrtype, __le32 value) + { +- return nla_put(skb, attrtype, sizeof(__le32), &value); ++ __le32 tmp = value; ++ ++ return nla_put(skb, attrtype, sizeof(__le32), &tmp); + } + + /** +@@ -857,7 +876,9 @@ static inline int nla_put_le32(struct sk + static inline int nla_put_u64_64bit(struct sk_buff *skb, int attrtype, + u64 value, int padattr) + { +- return nla_put_64bit(skb, attrtype, sizeof(u64), &value, padattr); ++ u64 tmp = value; ++ ++ return nla_put_64bit(skb, attrtype, sizeof(u64), &tmp, padattr); + } + + /** +@@ -870,7 +891,9 @@ static inline int nla_put_u64_64bit(stru + static inline int nla_put_be64(struct sk_buff *skb, int attrtype, __be64 value, + int padattr) + { +- return nla_put_64bit(skb, attrtype, sizeof(__be64), &value, padattr); ++ __be64 tmp = value; ++ ++ return nla_put_64bit(skb, attrtype, sizeof(__be64), &tmp, padattr); + } + + /** +@@ -883,7 +906,9 @@ static inline int nla_put_be64(struct sk + static inline int nla_put_net64(struct sk_buff *skb, int attrtype, __be64 value, + int padattr) + { +- return nla_put_be64(skb, attrtype | NLA_F_NET_BYTEORDER, value, ++ __be64 tmp = value; ++ ++ return nla_put_be64(skb, attrtype | NLA_F_NET_BYTEORDER, tmp, + padattr); + } + +@@ -897,7 +922,9 @@ static inline int nla_put_net64(struct s + static inline int nla_put_le64(struct sk_buff *skb, int attrtype, __le64 value, + int padattr) + { +- return nla_put_64bit(skb, attrtype, sizeof(__le64), &value, padattr); ++ __le64 tmp = value; ++ ++ return nla_put_64bit(skb, attrtype, sizeof(__le64), &tmp, padattr); + } + + /** +@@ -908,7 +935,9 @@ static inline int nla_put_le64(struct sk + */ + static inline int nla_put_s8(struct sk_buff *skb, int attrtype, s8 value) + { +- return nla_put(skb, attrtype, sizeof(s8), &value); ++ s8 tmp = value; ++ ++ return nla_put(skb, attrtype, sizeof(s8), &tmp); + } + + /** +@@ -919,7 +948,9 @@ static inline int nla_put_s8(struct sk_b + */ + static inline int nla_put_s16(struct sk_buff *skb, int attrtype, s16 value) + { +- return nla_put(skb, attrtype, sizeof(s16), &value); ++ s16 tmp = value; ++ ++ return nla_put(skb, attrtype, sizeof(s16), &tmp); + } + + /** +@@ -930,7 +961,9 @@ static inline int nla_put_s16(struct sk_ + */ + static inline int nla_put_s32(struct sk_buff *skb, int attrtype, s32 value) + { +- return nla_put(skb, attrtype, sizeof(s32), &value); ++ s32 tmp = value; ++ ++ return nla_put(skb, attrtype, sizeof(s32), &tmp); + } + + /** +@@ -943,7 +976,9 @@ static inline int nla_put_s32(struct sk_ + static inline int nla_put_s64(struct sk_buff *skb, int attrtype, s64 value, + int padattr) + { +- return nla_put_64bit(skb, attrtype, sizeof(s64), &value, padattr); ++ s64 tmp = value; ++ ++ return nla_put_64bit(skb, attrtype, sizeof(s64), &tmp, padattr); + } + + /** +@@ -993,7 +1028,9 @@ static inline int nla_put_msecs(struct s + static inline int nla_put_in_addr(struct sk_buff *skb, int attrtype, + __be32 addr) + { +- return nla_put_be32(skb, attrtype, addr); ++ __be32 tmp = addr; ++ ++ return nla_put_be32(skb, attrtype, tmp); + } + + /** diff --git a/queue-4.9/rocker-fix-rocker_tlv_put_-functions-for-kasan.patch b/queue-4.9/rocker-fix-rocker_tlv_put_-functions-for-kasan.patch new file mode 100644 index 00000000000..8bdcfcad7b4 --- /dev/null +++ b/queue-4.9/rocker-fix-rocker_tlv_put_-functions-for-kasan.patch @@ -0,0 +1,102 @@ +From 6098d7ddd62f532f80ee2a4b01aca500a8e4e9e4 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 22 Sep 2017 23:29:18 +0200 +Subject: rocker: fix rocker_tlv_put_* functions for KASAN + +From: Arnd Bergmann + +commit 6098d7ddd62f532f80ee2a4b01aca500a8e4e9e4 upstream. + +Inlining these functions creates lots of stack variables that each take +64 bytes when KASAN is enabled, leading to this warning about potential +stack overflow: + +drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 'ofdpa_cmd_flow_tbl_add': +drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of 2752 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] + +gcc-8 can now consolidate the stack slots itself, but on older versions +we get the same behavior by using a temporary variable that holds a +copy of the inline function argument. + +Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 +Signed-off-by: Arnd Bergmann +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/rocker/rocker_tlv.h | 48 +++++++++++++++++++------------ + 1 file changed, 30 insertions(+), 18 deletions(-) + +--- a/drivers/net/ethernet/rocker/rocker_tlv.h ++++ b/drivers/net/ethernet/rocker/rocker_tlv.h +@@ -139,40 +139,52 @@ rocker_tlv_start(struct rocker_desc_info + int rocker_tlv_put(struct rocker_desc_info *desc_info, + int attrtype, int attrlen, const void *data); + +-static inline int rocker_tlv_put_u8(struct rocker_desc_info *desc_info, +- int attrtype, u8 value) ++static inline int ++rocker_tlv_put_u8(struct rocker_desc_info *desc_info, int attrtype, u8 value) + { +- return rocker_tlv_put(desc_info, attrtype, sizeof(u8), &value); ++ u8 tmp = value; /* work around GCC PR81715 */ ++ ++ return rocker_tlv_put(desc_info, attrtype, sizeof(u8), &tmp); + } + +-static inline int rocker_tlv_put_u16(struct rocker_desc_info *desc_info, +- int attrtype, u16 value) ++static inline int ++rocker_tlv_put_u16(struct rocker_desc_info *desc_info, int attrtype, u16 value) + { +- return rocker_tlv_put(desc_info, attrtype, sizeof(u16), &value); ++ u16 tmp = value; ++ ++ return rocker_tlv_put(desc_info, attrtype, sizeof(u16), &tmp); + } + +-static inline int rocker_tlv_put_be16(struct rocker_desc_info *desc_info, +- int attrtype, __be16 value) ++static inline int ++rocker_tlv_put_be16(struct rocker_desc_info *desc_info, int attrtype, __be16 value) + { +- return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), &value); ++ __be16 tmp = value; ++ ++ return rocker_tlv_put(desc_info, attrtype, sizeof(__be16), &tmp); + } + +-static inline int rocker_tlv_put_u32(struct rocker_desc_info *desc_info, +- int attrtype, u32 value) ++static inline int ++rocker_tlv_put_u32(struct rocker_desc_info *desc_info, int attrtype, u32 value) + { +- return rocker_tlv_put(desc_info, attrtype, sizeof(u32), &value); ++ u32 tmp = value; ++ ++ return rocker_tlv_put(desc_info, attrtype, sizeof(u32), &tmp); + } + +-static inline int rocker_tlv_put_be32(struct rocker_desc_info *desc_info, +- int attrtype, __be32 value) ++static inline int ++rocker_tlv_put_be32(struct rocker_desc_info *desc_info, int attrtype, __be32 value) + { +- return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), &value); ++ __be32 tmp = value; ++ ++ return rocker_tlv_put(desc_info, attrtype, sizeof(__be32), &tmp); + } + +-static inline int rocker_tlv_put_u64(struct rocker_desc_info *desc_info, +- int attrtype, u64 value) ++static inline int ++rocker_tlv_put_u64(struct rocker_desc_info *desc_info, int attrtype, u64 value) + { +- return rocker_tlv_put(desc_info, attrtype, sizeof(u64), &value); ++ u64 tmp = value; ++ ++ return rocker_tlv_put(desc_info, attrtype, sizeof(u64), &tmp); + } + + static inline struct rocker_tlv * diff --git a/queue-4.9/series b/queue-4.9/series index 4ef409188bb..4d6d141fdbb 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -78,3 +78,15 @@ socket-bpf-fix-possible-use-after-free.patch powerpc-64s-use-emergency-stack-for-kernel-tm-bad-thing-program-checks.patch powerpc-tm-fix-illegal-tm-state-in-signal-handler.patch percpu-make-this_cpu_generic_read-atomic-w.r.t.-interrupts.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 +hid-wacom-leds-don-t-try-to-control-the-ekr-s-read-only-leds.patch +hid-wacom-always-increment-hdev-refcount-within-wacom_get_hdev_data.patch +hid-wacom-bits-shifted-too-much-for-9th-and-10th-buttons.patch +rocker-fix-rocker_tlv_put_-functions-for-kasan.patch +netlink-fix-nla_put_-u8-u16-u32-for-kasan.patch diff --git a/queue-4.9/stm-class-fix-a-use-after-free.patch b/queue-4.9/stm-class-fix-a-use-after-free.patch new file mode 100644 index 00000000000..615977ce19a --- /dev/null +++ b/queue-4.9/stm-class-fix-a-use-after-free.patch @@ -0,0 +1,40 @@ +From fd085bb1766d6a598f53af2308374a546a49775a Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Tue, 19 Sep 2017 18:47:40 +0300 +Subject: stm class: Fix a use-after-free + +From: Alexander Shishkin + +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 +Fixes: 7bd1d4093c2 ("stm class: Introduce an abstraction for System Trace Module devices") +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -1119,7 +1119,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); +