--- /dev/null
+From 9e3440481845b2ec22508f60837ee2cab2b6054f Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Thu, 16 Feb 2017 01:44:37 +0100
+Subject: ARM: 8658/1: uaccess: fix zeroing of 64-bit get_user()
+
+From: Kees Cook <keescook@chromium.org>
+
+commit 9e3440481845b2ec22508f60837ee2cab2b6054f upstream.
+
+The 64-bit get_user() wasn't clearing the high word due to a typo in the
+error handler. The exception handler entry was already correct, though.
+Noticed during recent usercopy test additions in lib/test_user_copy.c.
+
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/lib/getuser.S | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/lib/getuser.S
++++ b/arch/arm/lib/getuser.S
+@@ -67,7 +67,7 @@ ENTRY(__get_user_4)
+ ENDPROC(__get_user_4)
+
+ ENTRY(__get_user_8)
+- check_uaccess r0, 8, r1, r2, __get_user_bad
++ check_uaccess r0, 8, r1, r2, __get_user_bad8
+ #ifdef CONFIG_THUMB2_KERNEL
+ 5: TUSER(ldr) r2, [r0]
+ 6: TUSER(ldr) r3, [r0, #4]
--- /dev/null
+From bb08c04dc867b5f392caec635c097d5d5fcd8c9f Mon Sep 17 00:00:00 2001
+From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Date: Tue, 14 Feb 2017 14:49:21 +0200
+Subject: drm/dp/mst: fix kernel oops when turning off secondary monitor
+
+From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+
+commit bb08c04dc867b5f392caec635c097d5d5fcd8c9f upstream.
+
+100% reproducible issue found on SKL SkullCanyon NUC with two external
+DP daisy-chained monitors in DP/MST mode. When turning off or changing
+the input of the second monitor the machine stops with a kernel
+oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly.
+
+This issue is traced to an inconsistent control flow in
+drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at the
+same time as 'req_payload.num_slots' is set to zero, but the pointer is
+dereferenced even when req_payload.num_slot is zero.
+
+The problematic dereference was introduced in commit dfda0df34
+("drm/mst: rework payload table allocation to conform better") and may
+impact all versions since v3.18
+
+The fix suggested by Chris Wilson removes the kernel oops and was found to
+work well after 10mn of monkey-testing with the second monitor power and
+input buttons
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990
+Fixes: dfda0df34264 ("drm/mst: rework payload table allocation to conform better.")
+Cc: Dave Airlie <airlied@redhat.com>
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com>
+Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
+Cc: Sean Paul <seanpaul@chromium.org>
+Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com>
+Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
+Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/1487076561-2169-1-git-send-email-jani.nikula@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/drm_dp_mst_topology.c
++++ b/drivers/gpu/drm/drm_dp_mst_topology.c
+@@ -1812,7 +1812,7 @@ int drm_dp_update_payload_part1(struct d
+ mgr->payloads[i].num_slots = req_payload.num_slots;
+ } else if (mgr->payloads[i].num_slots) {
+ mgr->payloads[i].num_slots = 0;
+- drm_dp_destroy_payload_step1(mgr, port, port->vcpi.vcpi, &mgr->payloads[i]);
++ drm_dp_destroy_payload_step1(mgr, port, mgr->payloads[i].vcpi, &mgr->payloads[i]);
+ req_payload.payload_state = mgr->payloads[i].payload_state;
+ mgr->payloads[i].start_slot = 0;
+ }
--- /dev/null
+From d74c67dd7800fc7aae381f272875c337f268806c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer@amd.com>
+Date: Wed, 15 Feb 2017 11:28:45 +0900
+Subject: drm/radeon: Use mode h/vdisplay fields to hide out of bounds HW cursor
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Michel Dänzer <michel.daenzer@amd.com>
+
+commit d74c67dd7800fc7aae381f272875c337f268806c upstream.
+
+The crtc_h/vdisplay fields may not match the CRTC viewport dimensions
+with special modes such as interlaced ones.
+
+Fixes the HW cursor disappearing in the bottom half of the screen with
+interlaced modes.
+
+Fixes: 6b16cf7785a4 ("drm/radeon: Hide the HW cursor while it's out of bounds")
+Reported-by: Ashutosh Kumar <ashutosh.kumar@amd.com>
+Tested-by: Sonny Jiang <sonny.jiang@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_cursor.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/radeon/radeon_cursor.c
++++ b/drivers/gpu/drm/radeon/radeon_cursor.c
+@@ -205,8 +205,8 @@ static int radeon_cursor_move_locked(str
+ }
+
+ if (x <= (crtc->x - w) || y <= (crtc->y - radeon_crtc->cursor_height) ||
+- x >= (crtc->x + crtc->mode.crtc_hdisplay) ||
+- y >= (crtc->y + crtc->mode.crtc_vdisplay))
++ x >= (crtc->x + crtc->mode.hdisplay) ||
++ y >= (crtc->y + crtc->mode.vdisplay))
+ goto out_of_bounds;
+
+ x += xorigin;
--- /dev/null
+From 137d01df511b3afe1f05499aea05f3bafc0fb221 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@ZenIV.linux.org.uk>
+Date: Sun, 19 Feb 2017 07:15:27 +0000
+Subject: Fix missing sanity check in /dev/sg
+
+From: Al Viro <viro@ZenIV.linux.org.uk>
+
+commit 137d01df511b3afe1f05499aea05f3bafc0fb221 upstream.
+
+What happens is that a write to /dev/sg is given a request with non-zero
+->iovec_count combined with zero ->dxfer_len. Or with ->dxferp pointing
+to an array full of empty iovecs.
+
+Having write permission to /dev/sg shouldn't be equivalent to the
+ability to trigger BUG_ON() while holding spinlocks...
+
+Found by Dmitry Vyukov and syzkaller.
+
+[ The BUG_ON() got changed to a WARN_ON_ONCE(), but this fixes the
+ underlying issue. - Linus ]
+
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Reported-by: Dmitry Vyukov <dvyukov@google.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/sg.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/scsi/sg.c
++++ b/drivers/scsi/sg.c
+@@ -1763,6 +1763,10 @@ sg_start_req(Sg_request *srp, unsigned c
+ return res;
+
+ iov_iter_truncate(&i, hp->dxfer_len);
++ if (!iov_iter_count(&i)) {
++ kfree(iov);
++ return -EINVAL;
++ }
+
+ res = blk_rq_map_user_iov(q, rq, md, &i, GFP_ATOMIC);
+ kfree(iov);
--- /dev/null
+From 6ba4d2722d06960102c981322035239cd66f7316 Mon Sep 17 00:00:00 2001
+From: Sahitya Tummala <stummala@codeaurora.org>
+Date: Wed, 8 Feb 2017 20:30:56 +0530
+Subject: fuse: fix use after free issue in fuse_dev_do_read()
+
+From: Sahitya Tummala <stummala@codeaurora.org>
+
+commit 6ba4d2722d06960102c981322035239cd66f7316 upstream.
+
+There is a potential race between fuse_dev_do_write()
+and request_wait_answer() contexts as shown below:
+
+TASK 1:
+__fuse_request_send():
+ |--spin_lock(&fiq->waitq.lock);
+ |--queue_request();
+ |--spin_unlock(&fiq->waitq.lock);
+ |--request_wait_answer():
+ |--if (test_bit(FR_SENT, &req->flags))
+ <gets pre-empted after it is validated true>
+ TASK 2:
+ fuse_dev_do_write():
+ |--clears bit FR_SENT,
+ |--request_end():
+ |--sets bit FR_FINISHED
+ |--spin_lock(&fiq->waitq.lock);
+ |--list_del_init(&req->intr_entry);
+ |--spin_unlock(&fiq->waitq.lock);
+ |--fuse_put_request();
+ |--queue_interrupt();
+ <request gets queued to interrupts list>
+ |--wake_up_locked(&fiq->waitq);
+ |--wait_event_freezable();
+ <as FR_FINISHED is set, it returns and then
+ the caller frees this request>
+
+Now, the next fuse_dev_do_read(), see interrupts list is not empty
+and then calls fuse_read_interrupt() which tries to access the request
+which is already free'd and gets the below crash:
+
+[11432.401266] Unable to handle kernel paging request at virtual address
+6b6b6b6b6b6b6b6b
+...
+[11432.418518] Kernel BUG at ffffff80083720e0
+[11432.456168] PC is at __list_del_entry+0x6c/0xc4
+[11432.463573] LR is at fuse_dev_do_read+0x1ac/0x474
+...
+[11432.679999] [<ffffff80083720e0>] __list_del_entry+0x6c/0xc4
+[11432.687794] [<ffffff80082c65e0>] fuse_dev_do_read+0x1ac/0x474
+[11432.693180] [<ffffff80082c6b14>] fuse_dev_read+0x6c/0x78
+[11432.699082] [<ffffff80081d5638>] __vfs_read+0xc0/0xe8
+[11432.704459] [<ffffff80081d5efc>] vfs_read+0x90/0x108
+[11432.709406] [<ffffff80081d67f0>] SyS_read+0x58/0x94
+
+As FR_FINISHED bit is set before deleting the intr_entry with input
+queue lock in request completion path, do the testing of this flag and
+queueing atomically with the same lock in queue_interrupt().
+
+Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/dev.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/fuse/dev.c
++++ b/fs/fuse/dev.c
+@@ -418,6 +418,10 @@ static void request_end(struct fuse_conn
+ static void queue_interrupt(struct fuse_iqueue *fiq, struct fuse_req *req)
+ {
+ spin_lock(&fiq->waitq.lock);
++ if (test_bit(FR_FINISHED, &req->flags)) {
++ spin_unlock(&fiq->waitq.lock);
++ return;
++ }
+ if (list_empty(&req->intr_entry)) {
+ list_add_tail(&req->intr_entry, &fiq->interrupts);
+ wake_up_locked(&fiq->waitq);
--- /dev/null
+From 25f71d1c3e98ef0e52371746220d66458eac75bc Mon Sep 17 00:00:00 2001
+From: Yang Yang <yang.yang29@zte.com.cn>
+Date: Fri, 30 Dec 2016 16:17:55 +0800
+Subject: futex: Move futex_init() to core_initcall
+
+From: Yang Yang <yang.yang29@zte.com.cn>
+
+commit 25f71d1c3e98ef0e52371746220d66458eac75bc upstream.
+
+The UEVENT user mode helper is enabled before the initcalls are executed
+and is available when the root filesystem has been mounted.
+
+The user mode helper is triggered by device init calls and the executable
+might use the futex syscall.
+
+futex_init() is marked __initcall which maps to device_initcall, but there
+is no guarantee that futex_init() is invoked _before_ the first device init
+call which triggers the UEVENT user mode helper.
+
+If the user mode helper uses the futex syscall before futex_init() then the
+syscall crashes with a NULL pointer dereference because the futex subsystem
+has not been initialized yet.
+
+Move futex_init() to core_initcall so futexes are initialized before the
+root filesystem is mounted and the usermode helper becomes available.
+
+[ tglx: Rewrote changelog ]
+
+Signed-off-by: Yang Yang <yang.yang29@zte.com.cn>
+Cc: jiang.biao2@zte.com.cn
+Cc: jiang.zhengxiong@zte.com.cn
+Cc: zhong.weidong@zte.com.cn
+Cc: deng.huali@zte.com.cn
+Cc: Peter Zijlstra <peterz@infradead.org>
+Link: http://lkml.kernel.org/r/1483085875-6130-1-git-send-email-yang.yang29@zte.com.cn
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/futex.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/futex.c
++++ b/kernel/futex.c
+@@ -3199,4 +3199,4 @@ static int __init futex_init(void)
+
+ return 0;
+ }
+-__initcall(futex_init);
++core_initcall(futex_init);
--- /dev/null
+From 722c5ac708b4f5c1fcfad5fed4c95234c8b06590 Mon Sep 17 00:00:00 2001
+From: IHARA Hiroka <ihara_h@live.jp>
+Date: Sun, 12 Feb 2017 18:34:53 -0800
+Subject: Input: elan_i2c - add ELAN0605 to the ACPI table
+
+From: IHARA Hiroka <ihara_h@live.jp>
+
+commit 722c5ac708b4f5c1fcfad5fed4c95234c8b06590 upstream.
+
+ELAN0605 has been confirmed to be a variant of ELAN0600, which is
+blacklisted in the hid-core to be managed by elan_i2c. This device can be
+found in Lenovo ideapad 310s (80U4000).
+
+Signed-off-by: Hiroka IHARA <ihara_h@live.jp>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/elan_i2c_core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/input/mouse/elan_i2c_core.c
++++ b/drivers/input/mouse/elan_i2c_core.c
+@@ -1232,6 +1232,7 @@ static const struct acpi_device_id elan_
+ { "ELAN0000", 0 },
+ { "ELAN0100", 0 },
+ { "ELAN0600", 0 },
++ { "ELAN0605", 0 },
+ { "ELAN1000", 0 },
+ { }
+ };
--- /dev/null
+From fc98c3c8c9dcafd67adcce69e6ce3191d5306c9c Mon Sep 17 00:00:00 2001
+From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
+Date: Sat, 18 Feb 2017 03:42:54 -0800
+Subject: printk: use rcuidle console tracepoint
+
+From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
+
+commit fc98c3c8c9dcafd67adcce69e6ce3191d5306c9c upstream.
+
+Use rcuidle console tracepoint because, apparently, it may be issued
+from an idle CPU:
+
+ hw-breakpoint: Failed to enable monitor mode on CPU 0.
+ hw-breakpoint: CPU 0 failed to disable vector catch
+
+ ===============================
+ [ ERR: suspicious RCU usage. ]
+ 4.10.0-rc8-next-20170215+ #119 Not tainted
+ -------------------------------
+ ./include/trace/events/printk.h:32 suspicious rcu_dereference_check() usage!
+
+ other info that might help us debug this:
+
+ RCU used illegally from idle CPU!
+ rcu_scheduler_active = 2, debug_locks = 0
+ RCU used illegally from extended quiescent state!
+ 2 locks held by swapper/0/0:
+ #0: (cpu_pm_notifier_lock){......}, at: [<c0237e2c>] cpu_pm_exit+0x10/0x54
+ #1: (console_lock){+.+.+.}, at: [<c01ab350>] vprintk_emit+0x264/0x474
+
+ stack backtrace:
+ CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc8-next-20170215+ #119
+ Hardware name: Generic OMAP4 (Flattened Device Tree)
+ console_unlock
+ vprintk_emit
+ vprintk_default
+ printk
+ reset_ctrl_regs
+ dbg_cpu_pm_notify
+ notifier_call_chain
+ cpu_pm_exit
+ omap_enter_idle_coupled
+ cpuidle_enter_state
+ cpuidle_enter_state_coupled
+ do_idle
+ cpu_startup_entry
+ start_kernel
+
+This RCU warning, however, is suppressed by lockdep_off() in printk().
+lockdep_off() increments the ->lockdep_recursion counter and thus
+disables RCU_LOCKDEP_WARN() and debug_lockdep_rcu_enabled(), which want
+lockdep to be enabled "current->lockdep_recursion == 0".
+
+Link: http://lkml.kernel.org/r/20170217015932.11898-1-sergey.senozhatsky@gmail.com
+Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
+Reported-by: Tony Lindgren <tony@atomide.com>
+Tested-by: Tony Lindgren <tony@atomide.com>
+Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Cc: Petr Mladek <pmladek@suse.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Tony Lindgren <tony@atomide.com>
+Cc: Russell King <rmk@armlinux.org.uk>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/printk/printk.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/printk/printk.c
++++ b/kernel/printk/printk.c
+@@ -1436,7 +1436,7 @@ static void call_console_drivers(int lev
+ {
+ struct console *con;
+
+- trace_console(text, len);
++ trace_console_rcuidle(text, len);
+
+ if (level >= console_loglevel && !ignore_loglevel)
+ return;
--- /dev/null
+From fd3fc0b4d7305fa7246622dcc0dec69c42443f45 Mon Sep 17 00:00:00 2001
+From: Johannes Thumshirn <jthumshirn@suse.de>
+Date: Tue, 31 Jan 2017 10:16:00 +0100
+Subject: scsi: don't BUG_ON() empty DMA transfers
+
+From: Johannes Thumshirn <jthumshirn@suse.de>
+
+commit fd3fc0b4d7305fa7246622dcc0dec69c42443f45 upstream.
+
+Don't crash the machine just because of an empty transfer. Use WARN_ON()
+combined with returning an error.
+
+Found by Dmitry Vyukov and syzkaller.
+
+[ Changed to "WARN_ON_ONCE()". Al has a patch that should fix the root
+ cause, but a BUG_ON() is not acceptable in any case, and a WARN_ON()
+ might still be a cause of excessive log spamming.
+
+ NOTE! If this warning ever triggers, we may end up leaking resources,
+ since this doesn't bother to try to clean the command up. So this
+ WARN_ON_ONCE() triggering does imply real problems. But BUG_ON() is
+ much worse.
+
+ People really need to stop using BUG_ON() for "this shouldn't ever
+ happen". It makes pretty much any bug worse. - Linus ]
+
+Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
+Reported-by: Dmitry Vyukov <dvyukov@google.com>
+Cc: James Bottomley <jejb@linux.vnet.ibm.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/scsi_lib.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/scsi_lib.c
++++ b/drivers/scsi/scsi_lib.c
+@@ -1120,7 +1120,8 @@ int scsi_init_io(struct scsi_cmnd *cmd)
+ bool is_mq = (rq->mq_ctx != NULL);
+ int error;
+
+- BUG_ON(!rq->nr_phys_segments);
++ if (WARN_ON_ONCE(!rq->nr_phys_segments))
++ return -EINVAL;
+
+ error = scsi_init_sgtable(rq, &cmd->sdb);
+ if (error)
tcp-fix-mark-propagation-with-fwmark_reflect-enabled.patch
+vfs-fix-uninitialized-flags-in-splice_to_pipe.patch
+siano-make-it-work-again-with-config_vmap_stack.patch
+fuse-fix-use-after-free-issue-in-fuse_dev_do_read.patch
+scsi-don-t-bug_on-empty-dma-transfers.patch
+fix-missing-sanity-check-in-dev-sg.patch
+input-elan_i2c-add-elan0605-to-the-acpi-table.patch
+drm-radeon-use-mode-h-vdisplay-fields-to-hide-out-of-bounds-hw-cursor.patch
+drm-dp-mst-fix-kernel-oops-when-turning-off-secondary-monitor.patch
+futex-move-futex_init-to-core_initcall.patch
+arm-8658-1-uaccess-fix-zeroing-of-64-bit-get_user.patch
+printk-use-rcuidle-console-tracepoint.patch
--- /dev/null
+From f9c85ee67164b37f9296eab3b754e543e4e96a1c Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Date: Tue, 14 Feb 2017 17:47:57 -0200
+Subject: [media] siano: make it work again with CONFIG_VMAP_STACK
+
+From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+
+commit f9c85ee67164b37f9296eab3b754e543e4e96a1c upstream.
+
+Reported as a Kaffeine bug:
+ https://bugs.kde.org/show_bug.cgi?id=375811
+
+The USB control messages require DMA to work. We cannot pass
+a stack-allocated buffer, as it is not warranted that the
+stack would be into a DMA enabled area.
+
+On Kernel 4.9, the default is to not accept DMA on stack anymore
+on x86 architecture. On other architectures, this has been a
+requirement since Kernel 2.2. So, after this patch, this driver
+should likely work fine on all archs.
+
+Tested with USB ID 2040:5510: Hauppauge Windham
+
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/usb/siano/smsusb.c | 18 +++++++++++++-----
+ 1 file changed, 13 insertions(+), 5 deletions(-)
+
+--- a/drivers/media/usb/siano/smsusb.c
++++ b/drivers/media/usb/siano/smsusb.c
+@@ -200,22 +200,30 @@ static int smsusb_start_streaming(struct
+ static int smsusb_sendrequest(void *context, void *buffer, size_t size)
+ {
+ struct smsusb_device_t *dev = (struct smsusb_device_t *) context;
+- struct sms_msg_hdr *phdr = (struct sms_msg_hdr *) buffer;
+- int dummy;
++ struct sms_msg_hdr *phdr;
++ int dummy, ret;
+
+ if (dev->state != SMSUSB_ACTIVE) {
+ pr_debug("Device not active yet\n");
+ return -ENOENT;
+ }
+
++ phdr = kmalloc(size, GFP_KERNEL);
++ if (!phdr)
++ return -ENOMEM;
++ memcpy(phdr, buffer, size);
++
+ pr_debug("sending %s(%d) size: %d\n",
+ smscore_translate_msg(phdr->msg_type), phdr->msg_type,
+ phdr->msg_length);
+
+ smsendian_handle_tx_message((struct sms_msg_data *) phdr);
+- smsendian_handle_message_header((struct sms_msg_hdr *)buffer);
+- return usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
+- buffer, size, &dummy, 1000);
++ smsendian_handle_message_header((struct sms_msg_hdr *)phdr);
++ ret = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
++ phdr, size, &dummy, 1000);
++
++ kfree(phdr);
++ return ret;
+ }
+
+ static char *smsusb1_fw_lkup[] = {
--- /dev/null
+From 5a81e6a171cdbd1fa8bc1fdd80c23d3d71816fac Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi <mszeredi@redhat.com>
+Date: Thu, 16 Feb 2017 17:49:02 +0100
+Subject: vfs: fix uninitialized flags in splice_to_pipe()
+
+From: Miklos Szeredi <mszeredi@redhat.com>
+
+commit 5a81e6a171cdbd1fa8bc1fdd80c23d3d71816fac upstream.
+
+Flags (PIPE_BUF_FLAG_PACKET, PIPE_BUF_FLAG_GIFT) could remain on the
+unused part of the pipe ring buffer. Previously splice_to_pipe() left
+the flags value alone, which could result in incorrect behavior.
+
+Uninitialized flags appears to have been there from the introduction of
+the splice syscall.
+
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/splice.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/splice.c
++++ b/fs/splice.c
+@@ -211,6 +211,7 @@ ssize_t splice_to_pipe(struct pipe_inode
+ buf->len = spd->partial[page_nr].len;
+ buf->private = spd->partial[page_nr].private;
+ buf->ops = spd->ops;
++ buf->flags = 0;
+ if (spd->flags & SPLICE_F_GIFT)
+ buf->flags |= PIPE_BUF_FLAG_GIFT;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
