commit b1cff0b2ed20d9a046a17605c544a914d365dfc8
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon May 8 07:49:54 2017 +0200

    Linux 4.10.15

commit de7b7a35c99e4eaeffd43c208b2cbbe5964bef7f
Author: Adrian Salido <salidoa@google.com>
Date:   Thu Apr 27 10:32:55 2017 -0700

    dm ioctl: prevent stack leak in dm ioctl call
    
    commit 4617f564c06117c7d1b611be49521a4430042287 upstream.
    
    When calling a dm ioctl that doesn't process any data
    (IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct
    dm_ioctl are left initialized.  Current code is incorrectly extending
    the size of data copied back to user, causing the contents of kernel
    stack to be leaked to user.  Fix by only copying contents before data
    and allow the functions processing the ioctl to override.
    
    Signed-off-by: Adrian Salido <salidoa@google.com>
    Reviewed-by: Alasdair G Kergon <agk@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8dee04de5defe97c38aa07590b533c6b487df75e
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Mar 12 06:18:58 2017 -0700

    hwmon: (it87) Avoid registering the same chip on both SIO addresses
    
    commit 8358378b22518d92424597503d3c1cd302a490b6 upstream.
    
    IT8705F is known to respond on both SIO addresses. Registering it twice
    may result in system lockups.
    
    Reported-by: Russell King <linux@armlinux.org.uk>
    Fixes: e84bd9535e2b ("hwmon: (it87) Add support for second Super-IO chip")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Cc: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ad66b968a0e57438017abcbadfd725b84281d806
Author: Stephen Hemminger <stephen@networkplumber.org>
Date:   Tue Mar 7 09:15:53 2017 -0800

    scsi: storvsc: Workaround for virtual DVD SCSI version
    
    commit f1c635b439a5c01776fe3a25b1e2dc546ea82e6f upstream.
    
    Hyper-V host emulation of SCSI for virtual DVD device reports SCSI
    version 0 (UNKNOWN) but is still capable of supporting REPORTLUN.
    
    Without this patch, a GEN2 Linux guest on Hyper-V will not boot 4.11
    successfully with virtual DVD ROM device. What happens is that the SCSI
    scan process falls back to doing sequential probing by INQUIRY.  But the
    storvsc driver has a previous workaround that masks/blocks all errors
    reports from INQUIRY (or MODE_SENSE) commands.  This workaround causes
    the scan to then populate a full set of bogus LUN's on the target and
    then sends kernel spinning off into a death spiral doing block reads on
    the non-existent LUNs.
    
    By setting the correct blacklist flags, the target with the DVD device
    is scanned with REPORTLUN and that works correctly.
    
    Patch needs to go in current 4.11, it is safe but not necessary in older
    kernels.
    
    Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
    Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc08ba650a2b92e44e7db33db68a7b2a2a035656
Author: Sachin Prabhu <sprabhu@redhat.com>
Date:   Fri Mar 3 15:41:38 2017 -0800

    Handle mismatched open calls
    
    commit 38bd49064a1ecb67baad33598e3d824448ab11ec upstream.
    
    A signal can interrupt a SendReceive call which result in incoming
    responses to the call being ignored. This is a problem for calls such as
    open which results in the successful response being ignored. This
    results in an open file resource on the server.
    
    The patch looks into responses which were cancelled after being sent and
    in case of successful open closes the open fids.
    
    For this patch, the check is only done in SendReceive2()
    
    RH-bz: 1403319
    
    Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Acked-by: Sachin Prabhu <sprabhu@redhat.com>
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 43c1696e5e91dc946325c2968c29e60423659abc
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jan 31 15:24:03 2017 +0100

    timerfd: Protect the might cancel mechanism proper
    
    commit 1e38da300e1e395a15048b0af1e5305bd91402f6 upstream.
    
    The handling of the might_cancel queueing is not properly protected, so
    parallel operations on the file descriptor can race with each other and
    lead to list corruptions or use after free.
    
    Protect the context for these operations with a seperate lock.
    
    The wait queue lock cannot be reused for this because that would create a
    lock inversion scenario vs. the cancel lock. Replacing might_cancel with an
    atomic (atomic_t or atomic bit) does not help either because it still can
    race vs. the actual list operation.
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: "linux-fsdevel@vger.kernel.org"
    Cc: syzkaller <syzkaller@googlegroups.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: linux-fsdevel@vger.kernel.org
    Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanos
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>