commit 13817987369afc8a65c6d7590cfca57f9da4a9a2
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Sep 7 08:37:34 2017 +0200

    Linux 4.12.11

commit 9c2144e80db88bb93966e4c7fb631bef9e57e3a5
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Fri Sep 1 18:55:33 2017 +0200

    epoll: fix race between ep_poll_callback(POLLFREE) and ep_free()/ep_remove()
    
    commit 138e4ad67afd5c6c318b056b4d17c17f2c0ca5c0 upstream.
    
    The race was introduced by me in commit 971316f0503a ("epoll:
    ep_unregister_pollwait() can use the freed pwq->whead").  I did not
    realize that nothing can protect eventpoll after ep_poll_callback() sets
    ->whead = NULL, only whead->lock can save us from the race with
    ep_free() or ep_remove().
    
    Move ->whead = NULL to the end of ep_poll_callback() and add the
    necessary barriers.
    
    TODO: cleanup the ewake/EPOLLEXCLUSIVE logic, it was confusing even
    before this patch.
    
    Hopefully this explains use-after-free reported by syzcaller:
    
            BUG: KASAN: use-after-free in debug_spin_lock_before
            ...
             _raw_spin_lock_irqsave+0x4a/0x60 kernel/locking/spinlock.c:159
             ep_poll_callback+0x29f/0xff0 fs/eventpoll.c:1148
    
    this is spin_lock(eventpoll->lock),
    
            ...
            Freed by task 17774:
            ...
             kfree+0xe8/0x2c0 mm/slub.c:3883
             ep_free+0x22c/0x2a0 fs/eventpoll.c:865
    
    Fixes: 971316f0503a ("epoll: ep_unregister_pollwait() can use the freed pwq->whead")
    Reported-by: 范龙飞 <long7573@126.com>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 38f5d65ad997efdded1ac08eeb0ca3f6190ff5f7
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Wed Jul 19 16:49:59 2017 +1000

    drm/nouveau/i2c/gf119-: add support for address-only transactions
    
    commit 13a86519202c5d119d83640d6f781f3181205d2c upstream.
    
    Since switching the I2C-over-AUX helpers, there have been regressions on
    some display combinations due to us not having support for "address only"
    transactions.
    
    This commits enables support for them for GF119 and newer.
    
    Earlier GPUs have been reverted to a custom I2C-over-AUX algorithm.
    
    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
    Cc: Ilia Mirkin <imirkin@alum.mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdacc5fcf4f905e732fb3420e20602da333285e9
Author: Changpeng Liu <changpeng.liu@intel.com>
Date:   Thu Aug 31 11:22:49 2017 +0800

    nvme: fix the definition of the doorbell buffer config support bit
    
    commit 223694b9ae8bfba99f3528d49d07a740af6ff95a upstream.
    
    NVMe 1.3 specification defines the Optional Admin Command Support feature
    flags, bit 8 set to '1' then the controller supports the Doorbell Buffer
    Config command. Bit 7 is used for Virtualization Mangement command.
    
    Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Fixes: f9f38e33 ("nvme: improve performance for virtual NVMe devices")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6d2779d8f0d834e552ed5f022e96137b768315c
Author: Xiangliang.Yu <Xiangliang.Yu@amd.com>
Date:   Wed Aug 16 14:25:51 2017 +0800

    drm/ttm: Fix accounting error when fail to get pages for pool
    
    commit 9afae2719273fa1d406829bf3498f82dbdba71c7 upstream.
    
    When fail to get needed page for pool, need to put allocated pages
    into pool. But current code has a miscalculation of allocated pages,
    correct it.
    
    Signed-off-by: Xiangliang.Yu <Xiangliang.Yu@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Monk Liu <monk.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c5b60edd786fe18b7be96b26ca980aa2bef0428
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Wed Aug 2 19:50:14 2017 +0200

    xfrm: policy: check policy direction value
    
    commit 7bab09631c2a303f87a7eb7e3d69e888673b9b7e upstream.
    
    The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
    as an array index. This can lead to an out-of-bound access, kernel lockup and
    DoS. Add a check for the 'dir' value.
    
    This fixes CVE-2017-11600.
    
    References: https://bugzilla.redhat.com/show_bug.cgi?id=1474928
    Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint address(es)")
    Reported-by: "bo Zhang" <zhangbo5891001@gmail.com>
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cc6f45db016886f6a4e91b249a923a61cebb996
Author: Stephan Mueller <smueller@chronox.de>
Date:   Thu Aug 10 08:06:18 2017 +0200

    lib/mpi: kunmap after finishing accessing buffer
    
    commit dea3eb8b452e36cf2dd572b0a797915ccf452ae6 upstream.
    
    Using sg_miter_start and sg_miter_next, the buffer of an SG is kmap'ed
    to *buff. The current code calls sg_miter_stop (and thus kunmap) on the
    SG entry before the last access of *buff.
    
    The patch moves the sg_miter_stop call after the last access to *buff to
    ensure that the memory pointed to by *buff is still mapped.
    
    Fixes: 4816c9406430 ("lib/mpi: Fix SG miter leak")
    Signed-off-by: Stephan Mueller <smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3deff1d3285f9516b2335644588fb09eaa291a2
Author: Zhoujie Wu <zjwu@marvell.com>
Date:   Mon Aug 21 11:02:09 2017 -0700

    mmc: sdhci-xenon: add set_power callback
    
    commit 99c14fc360dbbb583a03ab985551b12b5c5ca4f1 upstream.
    
    Xenon sdh controller requests proper SD bus voltage select
    bits programmed even with vmmc power supply. Any reserved
    value(100b-000b) programmed in this field will lead to controller
    ignore SD bus power bit and keep its value at zero.
    Add set_power callback to handle this.
    
    Signed-off-by: Zhoujie Wu <zjwu@marvell.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality")
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d767ccb7c387b0eed712ae38100aded44710ebe5
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Thu Aug 31 16:47:43 2017 +0200

    wl1251: add a missing spin_lock_init()
    
    commit f581a0dd744fe32b0a8805e279c59ec1ac676d60 upstream.
    
    wl1251: add a missing spin_lock_init()
    
    This fixes the following kernel warning:
    
     [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745
     [ 5668.771850]  lock: 0xce63ef20, .magic: 00000000, .owner: <none>/-1,
     .owner_cpu: 0
     [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: G        W
     4.12.0-03002-gec979a4-dirty #40
     [ 5668.772796] Hardware name: Nokia RX-51 board
     [ 5668.773071] Workqueue: phy1 wl1251_irq_work
     [ 5668.773345] [<c010c9e4>] (unwind_backtrace) from [<c010a274>]
     (show_stack+0x10/0x14)
     [ 5668.773803] [<c010a274>] (show_stack) from [<c01545a4>]
     (do_raw_spin_lock+0x6c/0xa0)
     [ 5668.774230] [<c01545a4>] (do_raw_spin_lock) from [<c06ca578>]
     (_raw_spin_lock_irqsave+0x10/0x18)
     [ 5668.774658] [<c06ca578>] (_raw_spin_lock_irqsave) from [<c048c010>]
     (wl1251_op_tx+0x38/0x5c)
     [ 5668.775115] [<c048c010>] (wl1251_op_tx) from [<c06a12e8>]
     (ieee80211_tx_frags+0x188/0x1c0)
     [ 5668.775543] [<c06a12e8>] (ieee80211_tx_frags) from [<c06a138c>]
     (__ieee80211_tx+0x6c/0x130)
     [ 5668.775970] [<c06a138c>] (__ieee80211_tx) from [<c06a3dbc>]
     (ieee80211_tx+0xdc/0x104)
     [ 5668.776367] [<c06a3dbc>] (ieee80211_tx) from [<c06a4af0>]
     (__ieee80211_subif_start_xmit+0x454/0x8c8)
     [ 5668.776824] [<c06a4af0>] (__ieee80211_subif_start_xmit) from
     [<c06a4f94>] (ieee80211_subif_start_xmit+0x30/0x2fc)
     [ 5668.777343] [<c06a4f94>] (ieee80211_subif_start_xmit) from
     [<c0578848>] (dev_hard_start_xmit+0x80/0x118)
    ...
    
        by adding the missing spin_lock_init().
    
    Reported-by: Pavel Machek <pavel@ucw.cz>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 619d31a0d2471e538f83dda6fc69ddd365b4ae06
Author: Sinclair Yeh <syeh@vmware.com>
Date:   Tue Aug 29 18:55:09 2017 +0200

    drm/vmwgfx: Fix F26 Wayland screen update issue
    
    commit 021aba761f2a6c12158afb9993524c300c01fae2 upstream.
    
    vmwgfx currently cannot support non-blocking commit because when
    vmw_*_crtc_page_flip is called, drm_atomic_nonblocking_commit()
    schedules the update on a thread.  This means vmw_*_crtc_page_flip
    cannot rely on the new surface being bound before the subsequent
    dirty and flush operations happen.
    
    Signed-off-by: Sinclair Yeh <syeh@vmware.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Reviewed-by: Charmaine Lee <charmainel@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 399081a50c48b3d7b205d08975c67aa53c391238
Author: Bart Van Assche <bart.vanassche@wdc.com>
Date:   Wed Aug 9 11:32:12 2017 -0700

    dm mpath: do not lock up a CPU with requeuing activity
    
    commit 1c23484c355ec360ca2f37914f8a4802c6baeead upstream.
    
    When using the block layer in single queue mode, get_request()
    returns ERR_PTR(-EAGAIN) if the queue is dying and the REQ_NOWAIT
    flag has been passed to get_request(). Avoid that the kernel
    reports soft lockup complaints in this case due to continuous
    requeuing activity.
    
    Fixes: 7083abbbf ("dm mpath: avoid that path removal can trigger an infinite loop")
    Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
    Tested-by: Laurence Oberman <loberman@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 77ab9e7fb4312d3b377690660f757d900fa9e171
Author: Steve French <smfrench@gmail.com>
Date:   Sun Aug 27 16:56:08 2017 -0500

    CIFS: remove endian related sparse warning
    
    commit 6e3c1529c39e92ed64ca41d53abadabbaa1d5393 upstream.
    
    Recent patch had an endian warning ie
    cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup()
    
    Signed-off-by: Steve French <smfrench@gmail.com>
    CC: Ronnie Sahlberg <lsahlber@redhat.com>
    Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0627f7136685595b33a20855630ce517b65fe55c
Author: Pavel Shilovsky <pshilov@microsoft.com>
Date:   Thu Aug 24 15:16:40 2017 -0700

    CIFS: Fix maximum SMB2 header size
    
    commit 9e37b1784f2be9397a903307574ee565bbadfd75 upstream.
    
    Currently the maximum size of SMB2/3 header is set incorrectly which
    leads to hanging of directory listing operations on encrypted SMB3
    connections. Fix this by setting the maximum size to 170 bytes that
    is calculated as RFC1002 length field size (4) + transform header
    size (52) + SMB2 header size (64) + create response size (56).
    
    Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Acked-by: Sachin Prabhu <sprabhu@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3e9dc4504b1f11e69baaa9b3779512d9cc6d83f
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Oct 1 01:35:55 2015 +0100

    alpha: uapi: Add support for __SANE_USERSPACE_TYPES__
    
    commit cec80d82142ab25c71eee24b529cfeaf17c43062 upstream.
    
    This fixes compiler errors in perf such as:
    
    tests/attr.c: In function 'store_event':
    tests/attr.c:66:27: error: format '%llu' expects argument of type 'long long unsigned int', but argument 6 has type '__u64 {aka long unsigned int}' [-Werror=format=]
      snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir,
                               ^
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Tested-by: Michael Cree <mcree@orcon.net.nz>
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae53897e22db8139d6ad8278599a122aba8dad7d
Author: Waiman Long <longman@redhat.com>
Date:   Thu Aug 24 12:04:29 2017 -0400

    cpuset: Fix incorrect memory_pressure control file mapping
    
    commit 1c08c22c874ac88799cab1f78c40f46110274915 upstream.
    
    The memory_pressure control file was incorrectly set up without
    a private value (0, by default). As a result, this control
    file was treated like memory_migrate on read. By adding back the
    FILE_MEMORY_PRESSURE private value, the correct memory pressure value
    will be returned.
    
    Signed-off-by: Waiman Long <longman@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Fixes: 7dbdb199d3bf ("cgroup: replace cftype->mode with CFTYPE_WORLD_WRITABLE")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd20ca80f807f828285b359ceedd8fc3754e64f2
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Aug 28 14:51:27 2017 -0700

    cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs
    
    commit b339752d054fb32863418452dff350a1086885b1 upstream.
    
    When !NUMA, cpumask_of_node(@node) equals cpu_online_mask regardless of
    @node.  The assumption seems that if !NUMA, there shouldn't be more than
    one node and thus reporting cpu_online_mask regardless of @node is
    correct.  However, that assumption was broken years ago to support
    DISCONTIGMEM and whether a system has multiple nodes or not is
    separately controlled by NEED_MULTIPLE_NODES.
    
    This means that, on a system with !NUMA && NEED_MULTIPLE_NODES,
    cpumask_of_node() will report cpu_online_mask for all possible nodes,
    indicating that the CPUs are associated with multiple nodes which is an
    impossible configuration.
    
    This bug has been around forever but doesn't look like it has caused any
    noticeable symptoms.  However, it triggers a WARN recently added to
    workqueue to verify NUMA affinity configuration.
    
    Fix it by reporting empty cpumask on non-zero nodes if !NUMA.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-and-tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d7aeba120fde73756a231e54c80a7bb3f435d23
Author: Yan, Zheng <zyan@redhat.com>
Date:   Fri Aug 4 11:22:31 2017 +0800

    ceph: fix readpage from fscache
    
    commit dd2bc473482eedc60c29cf00ad12568ce40ce511 upstream.
    
    ceph_readpage() unlocks page prematurely prematurely in the case
    that page is reading from fscache. Caller of readpage expects that
    page is uptodate when it get unlocked. So page shoule get locked
    by completion callback of fscache_read_or_alloc_pages()
    
    Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3010084e111013917c5b53ad564bc9711810576
Author: Mel Gorman <mgorman@techsingularity.net>
Date:   Thu Aug 31 16:15:30 2017 -0700

    mm, madvise: ensure poisoned pages are removed from per-cpu lists
    
    commit c461ad6a63b37ba74632e90c063d14823c884247 upstream.
    
    Wendy Wang reported off-list that a RAS HWPOISON-SOFT test case failed
    and bisected it to the commit 479f854a207c ("mm, page_alloc: defer
    debugging checks of pages allocated from the PCP").
    
    The problem is that a page that was poisoned with madvise() is reused.
    The commit removed a check that would trigger if DEBUG_VM was enabled
    but re-enabling the check only fixes the problem as a side-effect by
    printing a bad_page warning and recovering.
    
    The root of the problem is that an madvise() can leave a poisoned page
    on the per-cpu list.  This patch drains all per-cpu lists after pages
    are poisoned so that they will not be reused.  Wendy reports that the
    test case in question passes with this patch applied.  While this could
    be done in a targeted fashion, it is over-complicated for such a rare
    operation.
    
    Link: http://lkml.kernel.org/r/20170828133414.7qro57jbepdcyz5x@techsingularity.net
    Fixes: 479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated from the PCP")
    Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
    Reported-by: Wang, Wendy <wendy.wang@intel.com>
    Tested-by: Wang, Wendy <wendy.wang@intel.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: "Hansen, Dave" <dave.hansen@intel.com>
    Cc: "Luck, Tony" <tony.luck@intel.com>
    Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
    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>

commit 8c46edd78de9ca55082d65a4646646748e8630a3
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Aug 31 16:15:26 2017 -0700

    mm, uprobes: fix multiple free of ->uprobes_state.xol_area
    
    commit 355627f518978b5167256d27492fe0b343aaf2f2 upstream.
    
    Commit 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for
    write killable") made it possible to kill a forking task while it is
    waiting to acquire its ->mmap_sem for write, in dup_mmap().
    
    However, it was overlooked that this introduced an new error path before
    the new mm_struct's ->uprobes_state.xol_area has been set to NULL after
    being copied from the old mm_struct by the memcpy in dup_mm().  For a
    task that has previously hit a uprobe tracepoint, this resulted in the
    'struct xol_area' being freed multiple times if the task was killed at
    just the right time while forking.
    
    Fix it by setting ->uprobes_state.xol_area to NULL in mm_init() rather
    than in uprobe_dup_mmap().
    
    With CONFIG_UPROBE_EVENTS=y, the bug can be reproduced by the same C
    program given by commit 2b7e8665b4ff ("fork: fix incorrect fput of
    ->exe_file causing use-after-free"), provided that a uprobe tracepoint
    has been set on the fork_thread() function.  For example:
    
        $ gcc reproducer.c -o reproducer -lpthread
        $ nm reproducer | grep fork_thread
        0000000000400719 t fork_thread
        $ echo "p $PWD/reproducer:0x719" > /sys/kernel/debug/tracing/uprobe_events
        $ echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
        $ ./reproducer
    
    Here is the use-after-free reported by KASAN:
    
        BUG: KASAN: use-after-free in uprobe_clear_state+0x1c4/0x200
        Read of size 8 at addr ffff8800320a8b88 by task reproducer/198
    
        CPU: 1 PID: 198 Comm: reproducer Not tainted 4.13.0-rc7-00015-g36fde05f3fb5 #255
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
        Call Trace:
         dump_stack+0xdb/0x185
         print_address_description+0x7e/0x290
         kasan_report+0x23b/0x350
         __asan_report_load8_noabort+0x19/0x20
         uprobe_clear_state+0x1c4/0x200
         mmput+0xd6/0x360
         do_exit+0x740/0x1670
         do_group_exit+0x13f/0x380
         get_signal+0x597/0x17d0
         do_signal+0x99/0x1df0
         exit_to_usermode_loop+0x166/0x1e0
         syscall_return_slowpath+0x258/0x2c0
         entry_SYSCALL_64_fastpath+0xbc/0xbe
    
        ...
    
        Allocated by task 199:
         save_stack_trace+0x1b/0x20
         kasan_kmalloc+0xfc/0x180
         kmem_cache_alloc_trace+0xf3/0x330
         __create_xol_area+0x10f/0x780
         uprobe_notify_resume+0x1674/0x2210
         exit_to_usermode_loop+0x150/0x1e0
         prepare_exit_to_usermode+0x14b/0x180
         retint_user+0x8/0x20
    
        Freed by task 199:
         save_stack_trace+0x1b/0x20
         kasan_slab_free+0xa8/0x1a0
         kfree+0xba/0x210
         uprobe_clear_state+0x151/0x200
         mmput+0xd6/0x360
         copy_process.part.8+0x605f/0x65d0
         _do_fork+0x1a5/0xbd0
         SyS_clone+0x19/0x20
         do_syscall_64+0x22f/0x660
         return_from_SYSCALL_64+0x0/0x7a
    
    Note: without KASAN, you may instead see a "Bad page state" message, or
    simply a general protection fault.
    
    Link: http://lkml.kernel.org/r/20170830033303.17927-1-ebiggers3@gmail.com
    Fixes: 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for write killable")
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Reported-by: Oleg Nesterov <oleg@redhat.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Konstantin Khlebnikov <koct9i@gmail.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    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>

commit 726bd348ead3883880912f686144854c8f2cf817
Author: Stephan Mueller <smueller@chronox.de>
Date:   Wed Aug 16 11:56:24 2017 +0200

    crypto: algif_skcipher - only call put_page on referenced and used pages
    
    commit 445a582738de6802669aeed9c33ca406c23c3b1f upstream.
    
    For asynchronous operation, SGs are allocated without a page mapped to
    them or with a page that is not used (ref-counted). If the SGL is freed,
    the code must only call put_page for an SG if there was a page assigned
    and ref-counted in the first place.
    
    This fixes a kernel crash when using io_submit with more than one iocb
    using the sendmsg and sendpage (vmsplice/splice) interface.
    
    Signed-off-by: Stephan Mueller <smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44c6b4a966258bd8d05817f7c994789120a34958
Author: Stephen Douthit <stephend@adiengineering.com>
Date:   Mon Aug 7 17:11:00 2017 -0400

    i2c: ismt: Return EMSGSIZE for block reads with bogus length
    
    commit ba201c4f5ebe13d7819081756378777d8153f23e upstream.
    
    Compare the number of bytes actually seen on the wire to the byte
    count field returned by the slave device.
    
    Previously we just overwrote the byte count returned by the slave
    with the real byte count and let the caller figure out if the
    message was sane.
    
    Signed-off-by: Stephen Douthit <stephend@adiengineering.com>
    Tested-by: Dan Priamo <danp@adiengineering.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7a90bfae634537530e1997fc352f8691127e6454
Author: Stephen Douthit <stephend@adiengineering.com>
Date:   Mon Aug 7 17:10:59 2017 -0400

    i2c: ismt: Don't duplicate the receive length for block reads
    
    commit b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream.
    
    According to Table 15-14 of the C2000 EDS (Intel doc #510524) the
    rx data pointed to by the descriptor dptr contains the byte count.
    
    desc->rxbytes reports all bytes read on the wire, including the
    "byte count" byte.  So if a device sends 4 bytes in response to a
    block read, on the wire and in the DMA buffer we see:
    
    count data1 data2 data3 data4
     0x04  0xde  0xad  0xbe  0xef
    
    That's what we want to return in data->block to the next level.
    
    Instead we were actually prefixing that with desc->rxbytes:
    
    bad
    count count data1 data2 data3 data4
     0x05  0x04  0xde  0xad  0xbe  0xef
    
    This was discovered while developing a BMC solution relying on the
    ipmi_ssif.c driver which was trying to interpret the bogus length
    field as part of the IPMI response.
    
    Signed-off-by: Stephen Douthit <stephend@adiengineering.com>
    Tested-by: Dan Priamo <danp@adiengineering.com>
    Acked-by: Neil Horman <nhorman@tuxdriver.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fb972d037512f59e4a9fffffe89ce59e815d8c4
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Mon Aug 14 14:28:14 2017 +0100

    crypto: chacha20 - fix handling of chunked input
    
    commit 4de437265eaac18f880d827f8e105b10de9b87a3 upstream.
    
    Commit 9ae433bc79f9 ("crypto: chacha20 - convert generic and x86 versions
    to skcipher") ported the existing chacha20 code to use the new skcipher
    API, and introduced a bug along the way. Unfortunately, the tcrypt tests
    did not catch the error, and it was only found recently by Tobias.
    
    Stefan kindly diagnosed the error, and proposed a fix which is similar
    to the one below, with the exception that 'walk.stride' is used rather
    than the hardcoded block size. This does not actually matter in this
    case, but it's a better example of how to use the skcipher walk API.
    
    Fixes: 9ae433bc79f9 ("crypto: chacha20 - convert generic and x86 ...")
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Reported-by: Tobias Brunner <tobias@strongswan.org>
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6b31ae8707a7b988ad9d56059b57cb361041bdbc
Author: Cameron Gutman <aicommander@gmail.com>
Date:   Thu Aug 31 11:52:20 2017 -0700

    Input: xpad - fix PowerA init quirk for some gamepad models
    
    commit f5308d1b83eba20e69df5e0926ba7257c8dd9074 upstream.
    
    The PowerA gamepad initialization quirk worked with the PowerA
    wired gamepad I had around (0x24c6:0x543a), but a user reported [0]
    that it didn't work for him, even though our gamepads shared the
    same vendor and product IDs.
    
    When I initially implemented the PowerA quirk, I wanted to avoid
    actually triggering the rumble action during init. My tests showed
    that my gamepad would work correctly even if it received a rumble
    of 0 intensity, so that's what I went with.
    
    Unfortunately, this apparently isn't true for all models (perhaps
    a firmware difference?). This non-working gamepad seems to require
    the real magic rumble packet that the Microsoft driver sends, which
    actually vibrates the gamepad. To counteract this effect, I still
    send the old zero-rumble PowerA quirk packet which cancels the
    rumble effect before the motors can spin up enough to vibrate.
    
    [0]: https://github.com/paroj/xpad/issues/48#issuecomment-313904867
    
    Reported-by: Kyle Beauchamp <kyleabeauchamp@gmail.com>
    Tested-by: Kyle Beauchamp <kyleabeauchamp@gmail.com>
    Fixes: 81093c9848a7 ("Input: xpad - support some quirky Xbox One pads")
    Signed-off-by: Cameron Gutman <aicommander@gmail.com>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ed56448f555a1ceb8f3568d0bc49eb0a37f09ec
Author: Anthony Martin <ality@pbrane.org>
Date:   Mon Aug 28 10:26:12 2017 -0700

    Input: synaptics - fix device info appearing different on reconnect
    
    commit 3f9db52dc87b003a1732f3e03f7f5fc8701ef4ad upstream.
    
    User-modified input settings no longer survive a suspend/resume cycle.
    Starting with 4.12, the touchpad is reinitialized on every reconnect
    because the hardware appears to be different. This can be reproduced
    by running the following as root:
    
        echo -n reconnect >/sys/devices/platform/i8042/serio1/drvctl
    
    A line like the following will show up in dmesg:
    
        [30378.295794] psmouse serio1: synaptics: hardware appears to be
                       different: id(149271-149271), model(114865-114865),
                       caps(d047b3-d047b1), ext(b40000-b40000).
    
    Note the single bit difference in caps: bit 1 (SYN_CAP_MULTIFINGER).
    
    This happens because we modify our stored copy of the device info
    capabilities when we enable advanced gesture mode but this change is
    not reflected in the actual hardware capabilities.
    
    It worked in the past because synaptics_query_hardware used to modify
    the stored synaptics_device_info struct instead of filling in a new
    one, as it does now.
    
    Fix it by no longer faking the SYN_CAP_MULTIFINGER bit when setting
    advanced gesture mode. This necessitated a small refactoring.
    
    Fixes: 6c53694fb222 ("Input: synaptics - split device info into a separate structure")
    Signed-off-by: Anthony Martin <ality@pbrane.org>
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 55a5a10ce349eb7a033532ad61f0b327b218c02e
Author: James Hogan <james.hogan@imgtec.com>
Date:   Sat Aug 12 21:36:09 2017 -0700

    irqchip: mips-gic: SYNC after enabling GIC region
    
    commit 2c0e8382386f618c85d20cb05e7cf7df8cdd382c upstream.
    
    A SYNC is required between enabling the GIC region and actually trying
    to use it, even if the first access is a read, otherwise its possible
    depending on the timing (and in my case depending on the precise
    alignment of certain kernel code) to hit CM bus errors on that first
    access.
    
    Add the SYNC straight after setting the GIC base.
    
    [paul.burton@imgtec.com:
      Changes later in this series increase our likelihood of hitting this
      by reducing the amount of code that runs between enabling the GIC &
      accessing it.]
    
    Fixes: a7057270c280 ("irqchip: mips-gic: Add device-tree support")
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Signed-off-by: Paul Burton <paul.burton@imgtec.com>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Jason Cooper <jason@lakedaemon.net>
    Cc: James Hogan <james.hogan@imgtec.com>
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/17019/
    Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6912089798119d9abd39c4954aa7bce1d640f11e
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jul 19 14:53:02 2017 +0200

    x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl
    
    commit 7206f9bf108eb9513d170c73f151367a1bdf3dbf upstream.
    
    The x86 version of insb/insw/insl uses an inline assembly that does
    not have the target buffer listed as an output. This can confuse
    the compiler, leading it to think that a subsequent access of the
    buffer is uninitialized:
    
      drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’:
      drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used uninitialized in this function [-Werror=uninitialized]
      drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/net/sb1000.c: In function 'sb1000_rx':
      drivers/net/sb1000.c:775:9: error: 'st[0]' is used uninitialized in this function [-Werror=uninitialized]
      drivers/net/sb1000.c:776:10: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/net/sb1000.c:784:11: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    I tried to mark the exact input buffer as an output here, but couldn't
    figure it out. As suggested by Linus, marking all memory as clobbered
    however is good enough too. For the outs operations, I also add the
    memory clobber, to force the input to be written to local variables.
    This is probably already guaranteed by the "asm volatile", but it can't
    hurt to do this for symmetry.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Link: http://lkml.kernel.org/r/20170719125310.2487451-5-arnd@arndb.de
    Link: https://lkml.org/lkml/2017/7/12/605
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 34ed350889ddd2023e70bfc33511971acf436b8d
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Tue Jul 11 15:19:22 2017 +0100

    arm64: mm: abort uaccess retries upon fatal signal
    
    commit 289d07a2dc6c6b6f3e4b8a62669320d99dbe6c3d upstream.
    
    When there's a fatal signal pending, arm64's do_page_fault()
    implementation returns 0. The intent is that we'll return to the
    faulting userspace instruction, delivering the signal on the way.
    
    However, if we take a fatal signal during fixing up a uaccess, this
    results in a return to the faulting kernel instruction, which will be
    instantly retried, resulting in the same fault being taken forever. As
    the task never reaches userspace, the signal is not delivered, and the
    task is left unkillable. While the task is stuck in this state, it can
    inhibit the forward progress of the system.
    
    To avoid this, we must ensure that when a fatal signal is pending, we
    apply any necessary fixup for a faulting kernel instruction. Thus we
    will return to an error path, and it is up to that code to make forward
    progress towards delivering the fatal signal.
    
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Laura Abbott <labbott@redhat.com>
    Reviewed-by: Steve Capper <steve.capper@arm.com>
    Tested-by: Steve Capper <steve.capper@arm.com>
    Reviewed-by: James Morse <james.morse@arm.com>
    Tested-by: James Morse <james.morse@arm.com>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>