commit c426a717c3c633c743bfa84af902012aa84063f4
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Feb 28 10:18:34 2018 +0100

    Linux 4.9.85

commit 22b5557f1fef4adaddfc9fe6a0cd72d0be69bef1
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Feb 23 14:06:21 2018 -0800

    x86/entry/64: Clear extra registers beyond syscall arguments, to reduce speculation attack surface
    
    commit 8e1eb3fa009aa7c0b944b3c8b26b07de0efb3200 upstream.
    
    At entry userspace may have (maliciously) populated the extra registers
    outside the syscall calling convention with arbitrary values that could
    be useful in a speculative execution (Spectre style) attack.
    
    Clear these registers to minimize the kernel's attack surface.
    
    Note, this only clears the extra registers and not the unused
    registers for syscalls less than 6 arguments, since those registers are
    likely to be clobbered well before their values could be put to use
    under speculation.
    
    Note, Linus found that the XOR instructions can be executed with
    minimized cost if interleaved with the PUSH instructions, and Ingo's
    analysis found that R10 and R11 should be included in the register
    clearing beyond the typical 'extra' syscall calling convention
    registers.
    
    Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Reported-by: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Cc: <stable@vger.kernel.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/151787988577.7847.16733592218894189003.stgit@dwillia2-desk3.amr.corp.intel.com
    [ Made small improvements to the changelog and the code comments. ]
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78b1cb3fe38a509dc0fdbdb52c742d4630db7502
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Feb 23 14:06:16 2018 -0800

    mm: fail get_vaddr_frames() for filesystem-dax mappings
    
    commit b7f0554a56f21fb3e636a627450a9add030889be upstream.
    
    Until there is a solution to the dma-to-dax vs truncate problem it is
    not safe to allow V4L2, Exynos, and other frame vector users to create
    long standing / irrevocable memory registrations against filesytem-dax
    vmas.
    
    [dan.j.williams@intel.com: add comment for vma_is_fsdax() check in get_vaddr_frames(), per Jan]
      Link: http://lkml.kernel.org/r/151197874035.26211.4061781453123083667.stgit@dwillia2-desk3.amr.corp.intel.com
    Link: http://lkml.kernel.org/r/151068939985.7446.15684639617389154187.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Cc: Inki Dae <inki.dae@samsung.com>
    Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
    Cc: Joonyoung Shim <jy0922.shim@samsung.com>
    Cc: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Doug Ledford <dledford@redhat.com>
    Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
    Cc: Jason Gunthorpe <jgg@mellanox.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Cc: <stable@vger.kernel.org>
    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 8f7cf88d59f0026af8d4c9fe0a14a445ba499d93
Author: Jan H. Schönherr <jschoenh@amazon.de>
Date:   Fri Feb 23 14:06:10 2018 -0800

    mm: Fix devm_memremap_pages() collision handling
    
    commit 77dd66a3c67c93ab401ccc15efff25578be281fd upstream.
    
    If devm_memremap_pages() detects a collision while adding entries
    to the radix-tree, we call pgmap_radix_release(). Unfortunately,
    the function removes *all* entries for the range -- including the
    entries that caused the collision in the first place.
    
    Modify pgmap_radix_release() to take an additional argument to
    indicate where to stop, so that only newly added entries are removed
    from the tree.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 9476df7d80df ("mm: introduce find_dev_pagemap()")
    Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 807e3365895ca847749864c482d95c0ec1c89461
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Feb 23 14:06:05 2018 -0800

    libnvdimm, dax: fix 1GB-aligned namespaces vs physical misalignment
    
    commit 41fce90f26333c4fa82e8e43b9ace86c4e8a0120 upstream.
    
    The following namespace configuration attempt:
    
        # ndctl create-namespace -e namespace0.0 -m devdax -a 1G -f
        libndctl: ndctl_dax_enable: dax0.1: failed to enable
          Error: namespace0.0: failed to enable
    
        failed to reconfigure namespace: No such device or address
    
    ...fails when the backing memory range is not physically aligned to 1G:
    
        # cat /proc/iomem | grep Persistent
        210000000-30fffffff : Persistent Memory (legacy)
    
    In the above example the 4G persistent memory range starts and ends on a
    256MB boundary.
    
    We handle this case correctly when needing to handle cases that violate
    section alignment (128MB) collisions against "System RAM", and we simply
    need to extend that padding/truncation for the 1GB alignment use case.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 315c562536c4 ("libnvdimm, pfn: add 'align' attribute...")
    Reported-and-tested-by: Jane Chu <jane.chu@oracle.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 00a6e639b58d23c0b6e36bb44b117afd2e245f52
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Feb 23 14:06:00 2018 -0800

    IB/core: disable memory registration of filesystem-dax vmas
    
    commit 5f1d43de54164dcfb9bfa542fcc92c1e1a1b6c1d upstream.
    
    Until there is a solution to the dma-to-dax vs truncate problem it is
    not safe to allow RDMA to create long standing memory registrations
    against filesytem-dax vmas.
    
    Link: http://lkml.kernel.org/r/151068941011.7446.7766030590347262502.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reported-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Jason Gunthorpe <jgg@mellanox.com>
    Acked-by: Doug Ledford <dledford@redhat.com>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Inki Dae <inki.dae@samsung.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Joonyoung Shim <jy0922.shim@samsung.com>
    Cc: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    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 53dfce305929bc3c7f4018b7b18027b74284802c
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Feb 23 14:05:54 2018 -0800

    v4l2: disable filesystem-dax mapping support
    
    commit b70131de648c2b997d22f4653934438013f407a1 upstream.
    
    V4L2 memory registrations are incompatible with filesystem-dax that
    needs the ability to revoke dma access to a mapping at will, or
    otherwise allow the kernel to wait for completion of DMA.  The
    filesystem-dax implementation breaks the traditional solution of
    truncate of active file backed mappings since there is no page-cache
    page we can orphan to sustain ongoing DMA.
    
    If v4l2 wants to support long lived DMA mappings it needs to arrange to
    hold a file lease or use some other mechanism so that the kernel can
    coordinate revoking DMA access when the filesystem needs to truncate
    mappings.
    
    Link: http://lkml.kernel.org/r/151068940499.7446.12846708245365671207.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reported-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Doug Ledford <dledford@redhat.com>
    Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
    Cc: Inki Dae <inki.dae@samsung.com>
    Cc: Jason Gunthorpe <jgg@mellanox.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Joonyoung Shim <jy0922.shim@samsung.com>
    Cc: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    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 b29ea3c0af9e6947f9384c25c5e4d8f34d9018b3
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Feb 23 14:05:49 2018 -0800

    mm: introduce get_user_pages_longterm
    
    commit 2bb6d2837083de722bfdc369cb0d76ce188dd9b4 upstream.
    
    Patch series "introduce get_user_pages_longterm()", v2.
    
    Here is a new get_user_pages api for cases where a driver intends to
    keep an elevated page count indefinitely.  This is distinct from usages
    like iov_iter_get_pages where the elevated page counts are transient.
    The iov_iter_get_pages cases immediately turn around and submit the
    pages to a device driver which will put_page when the i/o operation
    completes (under kernel control).
    
    In the longterm case userspace is responsible for dropping the page
    reference at some undefined point in the future.  This is untenable for
    filesystem-dax case where the filesystem is in control of the lifetime
    of the block / page and needs reasonable limits on how long it can wait
    for pages in a mapping to become idle.
    
    Fixing filesystems to actually wait for dax pages to be idle before
    blocks from a truncate/hole-punch operation are repurposed is saved for
    a later patch series.
    
    Also, allowing longterm registration of dax mappings is a future patch
    series that introduces a "map with lease" semantic where the kernel can
    revoke a lease and force userspace to drop its page references.
    
    I have also tagged these for -stable to purposely break cases that might
    assume that longterm memory registrations for filesystem-dax mappings
    were supported by the kernel.  The behavior regression this policy
    change implies is one of the reasons we maintain the "dax enabled.
    Warning: EXPERIMENTAL, use at your own risk" notification when mounting
    a filesystem in dax mode.
    
    It is worth noting the device-dax interface does not suffer the same
    constraints since it does not support file space management operations
    like hole-punch.
    
    This patch (of 4):
    
    Until there is a solution to the dma-to-dax vs truncate problem it is
    not safe to allow long standing memory registrations against
    filesytem-dax vmas.  Device-dax vmas do not have this problem and are
    explicitly allowed.
    
    This is temporary until a "memory registration with layout-lease"
    mechanism can be implemented for the affected sub-systems (RDMA and
    V4L2).
    
    [akpm@linux-foundation.org: use kcalloc()]
    Link: http://lkml.kernel.org/r/151068939435.7446.13560129395419350737.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Suggested-by: Christoph Hellwig <hch@lst.de>
    Cc: Doug Ledford <dledford@redhat.com>
    Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
    Cc: Inki Dae <inki.dae@samsung.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Jason Gunthorpe <jgg@mellanox.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Joonyoung Shim <jy0922.shim@samsung.com>
    Cc: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    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 be38759eb2d697f9e907eddfbb8d33aa26d37acc
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Feb 23 14:05:43 2018 -0800

    device-dax: implement ->split() to catch invalid munmap attempts
    
    commit 9702cffdbf2129516db679e4467db81e1cd287da upstream.
    
    Similar to how device-dax enforces that the 'address', 'offset', and
    'len' parameters to mmap() be aligned to the device's fundamental
    alignment, the same constraints apply to munmap().  Implement ->split()
    to fail munmap calls that violate the alignment constraint.
    
    Otherwise, we later fail VM_BUG_ON checks in the unmap_page_range() path
    with crash signatures of the form:
    
        vma ffff8800b60c8a88 start 00007f88c0000000 end 00007f88c0e00000
        next           (null) prev           (null) mm ffff8800b61150c0
        prot 8000000000000027 anon_vma           (null) vm_ops ffffffffa0091240
        pgoff 0 file ffff8800b638ef80 private_data           (null)
        flags: 0x380000fb(read|write|shared|mayread|maywrite|mayexec|mayshare|softdirty|mixedmap|hugepage)
        ------------[ cut here ]------------
        kernel BUG at mm/huge_memory.c:2014!
        [..]
        RIP: 0010:__split_huge_pud+0x12a/0x180
        [..]
        Call Trace:
         unmap_page_range+0x245/0xa40
         ? __vma_adjust+0x301/0x990
         unmap_vmas+0x4c/0xa0
         unmap_region+0xae/0x120
         ? __vma_rb_erase+0x11a/0x230
         do_munmap+0x276/0x410
         vm_munmap+0x6a/0xa0
         SyS_munmap+0x1d/0x30
    
    Link: http://lkml.kernel.org/r/151130418681.4029.7118245855057952010.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reported-by: Jeff Moyer <jmoyer@redhat.com>
    Cc: <stable@vger.kernel.org>
    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 29c969c3031b20595f6c3a0d16348cf6d11d8a13
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Feb 23 14:05:38 2018 -0800

    libnvdimm: fix integer overflow static analysis warning
    
    commit 58738c495e15badd2015e19ff41f1f1ed55200bc upstream.
    
    Dan reports:
        The patch 62232e45f4a2: "libnvdimm: control (ioctl) messages for
        nvdimm_bus and nvdimm devices" from Jun 8, 2015, leads to the
        following static checker warning:
    
                drivers/nvdimm/bus.c:1018 __nd_ioctl()
                warn: integer overflows 'buf_len'
    
        From a casual review, this seems like it might be a real bug.  On
        the first iteration we load some data into in_env[].  On the second
        iteration we read a use controlled "in_size" from nd_cmd_in_size().
        It can go up to UINT_MAX - 1.  A high number means we will fill the
        whole in_env[] buffer.  But we potentially keep looping and adding
        more to in_len so now it can be any value.
    
        It simple enough to change, but it feels weird that we keep looping
        even though in_env is totally full.  Shouldn't we just return an
        error if we don't have space for desc->in_num.
    
    We keep looping because the size of the total input is allowed to be
    bigger than the 'envelope' which is a subset of the payload that tells
    us how much data to expect. For safety explicitly check that buf_len
    does not overflow which is what the checker flagged.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 62232e45f4a2: "libnvdimm: control (ioctl) messages for nvdimm_bus..."
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f06c2c659ccad2c5da074311a6980cd888ea2779
Author: Jan Kara <jack@suse.cz>
Date:   Fri Feb 23 14:05:33 2018 -0800

    fs/dax.c: fix inefficiency in dax_writeback_mapping_range()
    
    commit 1eb643d02b21412e603b42cdd96010a2ac31c05f upstream.
    
    dax_writeback_mapping_range() fails to update iteration index when
    searching radix tree for entries needing cache flushing.  Thus each
    pagevec worth of entries is searched starting from the start which is
    inefficient and prone to livelocks.  Update index properly.
    
    Link: http://lkml.kernel.org/r/20170619124531.21491-1-jack@suse.cz
    Fixes: 9973c98ecfda3 ("dax: add support for fsync/sync")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: <stable@vger.kernel.org>
    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 f2562ed549054d3f7dfcc17ac17975440a33dcde
Author: Ross Zwisler <ross.zwisler@linux.intel.com>
Date:   Fri Feb 23 14:05:27 2018 -0800

    mm: avoid spurious 'bad pmd' warning messages
    
    commit d0f0931de936a0a468d7e59284d39581c16d3a73 upstream.
    
    When the pmd_devmap() checks were added by 5c7fb56e5e3f ("mm, dax:
    dax-pmd vs thp-pmd vs hugetlbfs-pmd") to add better support for DAX huge
    pages, they were all added to the end of if() statements after existing
    pmd_trans_huge() checks.  So, things like:
    
      -       if (pmd_trans_huge(*pmd))
      +       if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))
    
    When further checks were added after pmd_trans_unstable() checks by
    commit 7267ec008b5c ("mm: postpone page table allocation until we have
    page to map") they were also added at the end of the conditional:
    
      +       if (pmd_trans_unstable(fe->pmd) || pmd_devmap(*fe->pmd))
    
    This ordering is fine for pmd_trans_huge(), but doesn't work for
    pmd_trans_unstable().  This is because DAX huge pages trip the bad_pmd()
    check inside of pmd_none_or_trans_huge_or_clear_bad() (called by
    pmd_trans_unstable()), which prints out a warning and returns 1.  So, we
    do end up doing the right thing, but only after spamming dmesg with
    suspicious looking messages:
    
      mm/pgtable-generic.c:39: bad pmd ffff8808daa49b88(84000001006000a5)
    
    Reorder these checks in a helper so that pmd_devmap() is checked first,
    avoiding the error messages, and add a comment explaining why the
    ordering is important.
    
    Fixes: commit 7267ec008b5c ("mm: postpone page table allocation until we have page to map")
    Link: http://lkml.kernel.org/r/20170522215749.23516-1-ross.zwisler@linux.intel.com
    Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Cc: Pawel Lebioda <pawel.lebioda@intel.com>
    Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Matthew Wilcox <mawilcox@microsoft.com>
    Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
    Cc: Dave Jiang <dave.jiang@intel.com>
    Cc: Xiong Zhou <xzhou@redhat.com>
    Cc: Eryu Guan <eguan@redhat.com>
    Cc: <stable@vger.kernel.org>
    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 f2915986f892dfb6201dfc821cee5696be1c9b86
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Feb 26 10:17:15 2018 -0800

    X.509: fix NULL dereference when restricting key with unsupported_sig
    
    commit 4b34968e77ad09628cfb3c4a7daf2adc2cefc6e8 upstream.
    
    The asymmetric key type allows an X.509 certificate to be added even if
    its signature's hash algorithm is not available in the crypto API.  In
    that case 'payload.data[asym_auth]' will be NULL.  But the key
    restriction code failed to check for this case before trying to use the
    signature, resulting in a NULL pointer dereference in
    key_or_keyring_common() or in restrict_link_by_signature().
    
    Fix this by returning -ENOPKG when the signature is unsupported.
    
    Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled and
    keyctl has support for the 'restrict_keyring' command:
    
        keyctl new_session
        keyctl restrict_keyring @s asymmetric builtin_trusted
        openssl req -new -sha512 -x509 -batch -nodes -outform der \
            | keyctl padd asymmetric desc @s
    
    Fixes: a511e1af8b12 ("KEYS: Move the point of trust determination to __key_link()")
    Cc: <stable@vger.kernel.org> # v4.7+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit febf108e6c82d981ac6306978129dccb75db8b64
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Feb 26 10:56:45 2018 -0800

    binder: add missing binder_unlock()
    
    When commit 4be5a2810489 ("binder: check for binder_thread allocation
    failure in binder_poll()") was applied to 4.4-stable and 4.9-stable it
    was forgotten to release the global binder lock in the new error path.
    The global binder lock wasn't removed until v4.14, by commit
    a60b890f607d ("binder: remove global binder lock").
    
    Fix the new error path to release the lock.
    
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65aeceb58fe4e49dc1e4a581296e21cc5186ce6d
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Thu Feb 8 17:46:01 2018 +0800

    drm/amdgpu: add new device to use atpx quirk
    
    commit 6e59de2048eb375a9bfcd39461ef841cd2a78962 upstream.
    
    The affected system (0x0813) is pretty similar to another one (0x0812),
    it also needs to use ATPX power control.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a58e8489cf51772810cb7d1e20147e21c255c69
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Jan 22 23:13:32 2018 -0500

    drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
    
    commit 458d876eb869d5a88b53074c6c271b8b9adc0f07 upstream.
    
    We only support vga_switcheroo and runtime pm on PX/HG systems
    so forcing runpm to 1 doesn't do anything useful anyway.
    
    Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so
    that the cleanup path is correct as well.  This mirrors what
    radeon does as well.
    
    v2: rework the patch originally sent by Lukas (Alex)
    
    Acked-by: Lukas Wunner <lukas@wunner.de>
    Reported-by: Lukas Wunner <lukas@wunner.de>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Lukas Wunner <lukas@wunner.de> (v1)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3a66f9739da86cb552336eb20664d16e757e3fc6
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Wed Dec 20 13:29:58 2017 -0500

    drm/amdgpu: add atpx quirk handling (v2)
    
    commit 052c299080cd6859f82a8154a7a673fafabe644c upstream.
    
    Add quirks for handling PX/HG systems.  In this case, add
    a quirk for a weston dGPU that only seems to properly power
    down using ATPX power control rather than HG (_PR3).
    
    v2: append a new weston XT
    
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v2)
    Reviewed-and-Tested-by: Junwei Zhang <Jerry.Zhang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Acked-by: Christian König <christian.koenig@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cf7780a6b0d242e77d8432298087fc4833f3a6ec
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Nov 21 12:10:57 2017 -0500

    drm/amdgpu: Add dpm quirk for Jet PRO (v2)
    
    commit f2e5262f75ecb40a6e56554e156a292ab9e1d1b7 upstream.
    
    Fixes stability issues.
    
    v2: clamp sclk to 600 Mhz
    
    Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103370
    Acked-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 18ec706ed4ce3fe5c9381471ef414fef6a82c779
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date:   Mon Feb 5 17:12:35 2018 +0900

    usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path
    
    commit 17aa31f13cad25daa19d3f923323f552e87bc874 upstream.
    
    This fixes an issue that a gadget driver (usb_f_fs) is possible to
    stop rx transactions after the usb-dmac is used because the following
    functions missed to set/check the "running" flag.
     - usbhsf_dma_prepare_pop_with_usb_dmac()
     - usbhsf_dma_pop_done_with_usb_dmac()
    
    So, if next transaction uses pio, the usbhsf_prepare_pop() can not
    start the transaction because the "running" flag is 0.
    
    Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
    Cc: <stable@vger.kernel.org> # v3.19+
    Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bedacf13d59b6da429780ba67f16fd0a92b1b8e
Author: Jack Pham <jackp@codeaurora.org>
Date:   Wed Jan 24 00:11:53 2018 -0800

    usb: gadget: f_fs: Process all descriptors during bind
    
    commit 6cf439e0d37463e42784271179c8a308fd7493c6 upstream.
    
    During _ffs_func_bind(), the received descriptors are evaluated
    to prepare for binding with the gadget in order to allocate
    endpoints and optionally set up OS descriptors. However, the
    high- and super-speed descriptors are only parsed based on
    whether the gadget_is_dualspeed() and gadget_is_superspeed()
    calls are true, respectively.
    
    This is a problem in case a userspace program always provides
    all of the {full,high,super,OS} descriptors when configuring a
    function. Then, for example if a gadget device is not capable
    of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
    is skipped, resulting in an incorrect offset calculation for
    the vla_ptr when moving on to the OS descriptors that follow.
    This causes ffs_do_os_descs() to fail as it is now looking at
    the SS descriptors' offset within the raw_descs buffer instead.
    
    _ffs_func_bind() should evaluate the descriptors unconditionally,
    so remove the checks for gadget speed.
    
    Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
    Cc: stable@vger.kernel.org
    Co-Developed-by: Mayank Rana <mrana@codeaurora.org>
    Signed-off-by: Mayank Rana <mrana@codeaurora.org>
    Signed-off-by: Jack Pham <jackp@codeaurora.org>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fe80d7385e744824443276fdfc6cfaa0a93da0cb
Author: Bin Liu <b-liu@ti.com>
Date:   Tue Feb 20 07:31:35 2018 -0600

    Revert "usb: musb: host: don't start next rx urb if current one failed"
    
    commit 44eb5e12b845cc8a0634f21b70ef07d774eb4b25 upstream.
    
    This reverts commit dbac5d07d13e330e6706813c9fde477140fb5d80.
    
    commit dbac5d07d13e ("usb: musb: host: don't start next rx urb if current one failed")
    along with commit b5801212229f ("usb: musb: host: clear rxcsr error bit if set")
    try to solve the issue described in [1], but the latter alone is
    sufficient, and the former causes the issue as in [2], so now revert it.
    
    [1] https://marc.info/?l=linux-usb&m=146173995117456&w=2
    [2] https://marc.info/?l=linux-usb&m=151689238420622&w=2
    
    Cc: stable@vger.kernel.org # v4.7+
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f04280fd570e2aad2cc0b8f6f678fe737efe829d
Author: Karsten Koop <kkoop@ld-didactic.de>
Date:   Fri Feb 9 09:12:06 2018 +0000

    usb: ldusb: add PIDs for new CASSY devices supported by this driver
    
    commit 52ad2bd8918158266fc88a05f95429b56b6a33c5 upstream.
    
    This patch adds support for new CASSY devices to the ldusb driver. The
    PIDs are also added to the ignore list in hid-quirks.
    
    Signed-off-by: Karsten Koop <kkoop@ld-didactic.de>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c0cbbf693968e55b024648637ff15581043aad0
Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date:   Fri Jan 12 18:18:05 2018 -0800

    usb: dwc3: gadget: Set maxpacket size for ep0 IN
    
    commit 6180026341e852a250e1f97ebdcf71684a3c81b9 upstream.
    
    There are 2 control endpoint structures for DWC3. However, the driver
    only updates the OUT direction control endpoint structure during
    ConnectDone event. DWC3 driver needs to update the endpoint max packet
    size for control IN endpoint as well. If the max packet size is not
    properly set, then the driver will incorrectly calculate the data
    transfer size and fail to send ZLP for HS/FS 3-stage control read
    transfer.
    
    The fix is simply to update the max packet size for the ep0 IN direction
    during ConnectDone event.
    
    Cc: stable@vger.kernel.org
    Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
    Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f1e00f5e3f123ed0313d3f736f9c583bd6441cc
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Sun Feb 18 16:53:59 2018 +0800

    drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA
    
    commit 06998a756a3865817b87a129a7e5d5bb66dc1ec3 upstream.
    
    Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display
    AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
    6bpc instead of 8 bpc.
    
    Hence, use 6 bpc quirk for this panel.
    
    Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"")
    BugLink: https://bugs.launchpad.net/bugs/1749420
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Cc: <stable@vger.kernel.org> # v4.8+
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180218085359.7817-1-kai.heng.feng@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b99be3b9e1d1ee5758f52df8ff76ccdad4ea815
Author: Jack Stocker <jackstocker.93@gmail.com>
Date:   Thu Feb 15 18:24:10 2018 +0000

    Add delay-init quirk for Corsair K70 RGB keyboards
    
    commit 7a1646d922577b5b48c0d222e03831141664bb59 upstream.
    
    Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
    Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
    start correctly at boot.
    
    Device ids found here:
    usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
    usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
    
    Signed-off-by: Jack Stocker <jackstocker.93@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8bd22b1828b81b16a0802b534261b1caeb26f3d0
Author: Michael Weiser <michael.weiser@gmx.de>
Date:   Thu Feb 1 23:13:38 2018 +0100

    arm64: Disable unhandled signal log messages by default
    
    commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.
    
    aarch64 unhandled signal kernel messages are very verbose, suggesting
    them to be more of a debugging aid:
    
    sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
    0x92000046, in sigsegv[400000+71000]
    CPU: 1 PID: 33 Comm: sigsegv Tainted: G        W        4.15.0-rc3+ #3
    Hardware name: linux,dummy-virt (DT)
    pstate: 60000000 (nZCv daif -PAN -UAO)
    pc : 0x4003f4
    lr : 0x4006bc
    sp : 0000fffffe94a060
    x29: 0000fffffe94a070 x28: 0000000000000000
    x27: 0000000000000000 x26: 0000000000000000
    x25: 0000000000000000 x24: 00000000004001b0
    x23: 0000000000486ac8 x22: 00000000004001c8
    x21: 0000000000000000 x20: 0000000000400be8
    x19: 0000000000400b30 x18: 0000000000484728
    x17: 000000000865ffc8 x16: 000000000000270f
    x15: 00000000000000b0 x14: 0000000000000002
    x13: 0000000000000001 x12: 0000000000000000
    x11: 0000000000000000 x10: 0008000020008008
    x9 : 000000000000000f x8 : ffffffffffffffff
    x7 : 0004000000000000 x6 : ffffffffffffffff
    x5 : 0000000000000000 x4 : 0000000000000000
    x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
    x1 : 000000000000000a x0 : 0000000000000000
    
    Disable them by default, so they can be enabled using
    /proc/sys/debug/exception-trace.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31fec948b3a25899647eb9f88284e54b6a8a4614
Author: AMAN DEEP <aman.deep@samsung.com>
Date:   Thu Feb 8 11:55:01 2018 +0800

    usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
    
    commit 46408ea558df13b110e0866b99624384a33bdeba upstream.
    
    There is a race condition between finish_unlinks->finish_urb() function
    and usb_kill_urb() in ohci controller case. The finish_urb calls
    spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call,
    then if during this time, usb_kill_urb is called for another endpoint,
    then new ed will be added to ed_rm_list at beginning for unlink, and
    ed_rm_list will point to newly added.
    
    When finish_urb() is completed in finish_unlinks() and ed->td_list
    becomes empty as in below code (in finish_unlinks() function):
    
            if (list_empty(&ed->td_list)) {
                    *last = ed->ed_next;
                    ed->ed_next = NULL;
            } else if (ohci->rh_state == OHCI_RH_RUNNING) {
                    *last = ed->ed_next;
                    ed->ed_next = NULL;
                    ed_schedule(ohci, ed);
            }
    
    The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
    and previously added ed by usb_kill_urb will be left unreferenced by
    ed_rm_list. This causes usb_kill_urb() hang forever waiting for
    finish_unlink to remove added ed from ed_rm_list.
    
    The main reason for hang in this race condtion is addition and removal
    of ed from ed_rm_list in the beginning during usb_kill_urb and later
    last* is modified in finish_unlinks().
    
    As suggested by Alan Stern, the solution for proper handling of
    ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
    any URBs. Then at the end, we can add ed back to the list if necessary.
    
    This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
    
    Fixes: 977dcfdc6031 ("USB: OHCI: don't lose track of EDs when a controller dies")
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    CC: <stable@vger.kernel.org>
    Signed-off-by: Aman Deep <aman.deep@samsung.com>
    Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4a41d4412de0517eaa531ae273c3a847c8031984
Author: Shigeru Yoshida <shigeru.yoshida@windriver.com>
Date:   Fri Feb 2 13:51:39 2018 +0800

    ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
    
    commit b2685bdacdaab065c172b97b55ab46c6be77a037 upstream.
    
    Running io_watchdog_func() while ohci_urb_enqueue() is running can
    cause a race condition where ohci->prev_frame_no is corrupted and the
    watchdog can mis-detect following error:
    
      ohci-platform 664a0800.usb: frame counter not updating; disabled
      ohci-platform 664a0800.usb: HC died; cleaning up
    
    Specifically, following scenario causes a race condition:
    
      1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
         and enters the critical section
      2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
         returns false
      3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number
         read by ohci_frame_no(ohci)
      4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
      5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
         flags) and exits the critical section
      6. Later, ohci_urb_enqueue() is called
      7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
         and enters the critical section
      8. The timer scheduled on step 4 expires and io_watchdog_func() runs
      9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags)
         and waits on it because ohci_urb_enqueue() is already in the
         critical section on step 7
     10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
         returns false
     11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number
         read by ohci_frame_no(ohci) because the frame number proceeded
         between step 3 and 6
     12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
     13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
         flags) and exits the critical section, then wake up
         io_watchdog_func() which is waiting on step 9
     14. io_watchdog_func() enters the critical section
     15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no
         variable to the frame number
     16. io_watchdog_func() compares frame_no and ohci->prev_frame_no
    
    On step 16, because this calling of io_watchdog_func() is scheduled on
    step 4, the frame number set in ohci->prev_frame_no is expected to the
    number set on step 3.  However, ohci->prev_frame_no is overwritten on
    step 11.  Because step 16 is executed soon after step 11, the frame
    number might not proceed, so ohci->prev_frame_no must equals to
    frame_no.
    
    To address above scenario, this patch introduces a special sentinel
    value IO_WATCHDOG_OFF and set this value to ohci->prev_frame_no when
    the watchdog is not pending or running.  When ohci_urb_enqueue()
    schedules the watchdog (step 4 and 12 above), it compares
    ohci->prev_frame_no to IO_WATCHDOG_OFF so that ohci->prev_frame_no is
    not overwritten while io_watchdog_func() is running.
    
    Signed-off-by: Shigeru Yoshida <Shigeru.Yoshida@windriver.com>
    Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c529ff430693180d0f2a57a44a19cc51009de3a4
Author: Casey Leedom <leedom@chelsio.com>
Date:   Thu Feb 15 20:03:18 2018 +0530

    PCI/cxgb4: Extend T3 PCI quirk to T4+ devices
    
    commit 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be upstream.
    
    We've run into a problem where our device is attached
    to a Virtual Machine and the use of the new pci_set_vpd_size()
    API doesn't help.  The VM kernel has been informed that
    the accesses are okay, but all of the actual VPD Capability
    Accesses are trapped down into the KVM Hypervisor where it
    goes ahead and imposes the silent denials.
    
    The right idea is to follow the kernel.org
    commit 1c7de2b4ff88 ("PCI: Enable access to non-standard VPD for
    Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored
    to establish a PCI Quirk for our T3-based adapters. This commit
    extends that PCI Quirk to cover Chelsio T4 devices and later.
    
    The advantage of this approach is that the VPD Size gets set early
    in the Base OS/Hypervisor Boot and doesn't require that the cxgb4
    driver even be available in the Base OS/Hypervisor.  Thus PF4 can
    be exported to a Virtual Machine and everything should work.
    
    Fixes: 67e658794ca1 ("cxgb4: Set VPD size so we can read both VPD structures")
    Cc: <stable@vger.kernel.org>  # v4.9+
    Signed-off-by: Casey Leedom <leedom@chelsio.com>
    Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
    Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2146b6ec0e96ab283c46f7391ddf3bf01f7975e2
Author: Shanker Donthineni <shankerd@codeaurora.org>
Date:   Wed Jan 31 18:03:42 2018 -0600

    irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq()
    
    commit 21ec30c0ef5234fb1039cc7c7737d885bf875a9e upstream.
    
    A DMB instruction can be used to ensure the relative order of only
    memory accesses before and after the barrier. Since writes to system
    registers are not memory operations, barrier DMB is not sufficient
    for observability of memory accesses that occur before ICC_SGI1R_EL1
    writes.
    
    A DSB instruction ensures that no instructions that appear in program
    order after the DSB instruction, can execute until the DSB instruction
    has completed.
    
    Cc: stable@vger.kernel.org
    Acked-by: Will Deacon <will.deacon@arm.com>,
    Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dcc92a16da6d56b946e79d354364b87e1b5ea5ea
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 20 21:58:21 2018 +0100

    x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()
    
    commit 85c615eb52222bc5fab6c7190d146bc59fac289e upstream.
    
    GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
    data from CPU 0 to all other CPUs, which when building a non-SMP
    kernel turns into a memcpy() with identical source and destination
    pointers:
    
     arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
     arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
       memcpy(per_cpu(cpu_msrs, cpu).multiplex,
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              per_cpu(cpu_msrs, 0).multiplex,
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              sizeof(struct op_msr) * model->num_virt_counters);
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
     arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
     arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
    
    I have analyzed a number of such warnings now: some are valid and the
    GCC warning is welcome. Others turned out to be false-positives, and
    GCC was changed to not warn about those any more. This is a corner case
    that is a false-positive but the GCC developers feel it's better to keep
    warning about it.
    
    In this case, it seems best to work around it by telling GCC
    a little more clearly that this code path is never hit with
    an IS_ENABLED() configuration check.
    
    Cc:stable as we also want old kernels to build cleanly with GCC-8.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Cc: Jessica Yu <jeyu@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Martin Sebor <msebor@gcc.gnu.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Robert Richter <rric@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: oprofile-list@lists.sf.net
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
    Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 964e8ceadfe6c30483e4b1131b9ddc9b1c069d50
Author: Lars-Peter Clausen <lars@metafoo.de>
Date:   Wed Feb 14 15:43:00 2018 +0100

    iio: adis_lib: Initialize trigger before requesting interrupt
    
    commit f027e0b3a774e10302207e91d304bbf99e3a8b36 upstream.
    
    The adis_probe_trigger() creates a new IIO trigger and requests an
    interrupt associated with the trigger. The interrupt uses the generic
    iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
    
    Currently the driver initializes some fields of the trigger structure after
    the interrupt has been requested. But an interrupt can fire as soon as it
    has been requested. This opens up a race condition.
    
    iio_trigger_generic_data_rdy_poll() will access the trigger data structure
    and dereference the ops field. If the ops field is not yet initialized this
    will result in a NULL pointer deref.
    
    It is not expected that the device generates an interrupt at this point, so
    typically this issue did not surface unless e.g. due to a hardware
    misconfiguration (wrong interrupt number, wrong polarity, etc.).
    
    But some newer devices from the ADIS family start to generate periodic
    interrupts in their power-on reset configuration and unfortunately the
    interrupt can not be masked in the device.  This makes the race condition
    much more visible and the following crash has been observed occasionally
    when booting a system using the ADIS16460.
    
            Unable to handle kernel NULL pointer dereference at virtual address 00000008
            pgd = c0004000
            [00000008] *pgd=00000000
            Internal error: Oops: 5 [#1] PREEMPT SMP ARM
            Modules linked in:
            CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
            Hardware name: Xilinx Zynq Platform
            task: ef04f640 task.stack: ef050000
            PC is at iio_trigger_notify_done+0x30/0x68
            LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
            pc : [<c042d868>]    lr : [<c042d924>]    psr: 60000193
            sp : ef051bb8  ip : 00000000  fp : ef106400
            r10: c081d80a  r9 : ef3bfa00  r8 : 00000087
            r7 : ef051bec  r6 : 00000000  r5 : ef3bfa00  r4 : ee92ab00
            r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : ee97e400
            Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
            Control: 18c5387d  Table: 0000404a  DAC: 00000051
            Process swapper/0 (pid: 1, stack limit = 0xef050210)
            [<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
            [<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
            [<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
            [<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
            [<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
            [<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
            [<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
            [<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
            [<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
            [<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
    
    To fix this make sure that the trigger is fully initialized before
    requesting the interrupt.
    
    Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library")
    Reported-by: Robin Getz <Robin.Getz@analog.com>
    Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97e604775d4170c4c6daea5318adf43d7a1f7f5f
Author: Stefan Windfeldt-Prytz <stefan.windfeldt@axis.com>
Date:   Thu Feb 15 15:02:53 2018 +0100

    iio: buffer: check if a buffer has been set up when poll is called
    
    commit 4cd140bda6494543f1c1b0ccceceaa44b676eef6 upstream.
    
    If no iio buffer has been set up and poll is called return 0.
    Without this check there will be a null pointer dereference when
    calling poll on a iio driver without an iio buffer.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Stefan Windfeldt-Prytz <stefan.windfeldt@axis.com>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 239ef9cf2695c7e6d2d0dc673b34a4123dde7425
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Tue Feb 13 12:18:41 2018 +0200

    RDMA/uverbs: Protect from command mask overflow
    
    commit 3f802b162dbf4a558ff98986449eddc717826209 upstream.
    
    The command number is not bounds checked against the command mask before it
    is shifted, resulting in an ubsan hit. This does not cause malfunction since
    the command number is eventually bounds checked, but we can make this ubsan
    clean by moving the bounds check to before the mask check.
    
    ================================================================================
    UBSAN: Undefined behaviour in
    drivers/infiniband/core/uverbs_main.c:647:21
    shift exponent 207 is too large for 64-bit type 'long long unsigned int'
    CPU: 0 PID: 446 Comm: syz-executor3 Not tainted 4.15.0-rc2+ #61
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
    Call Trace:
    dump_stack+0xde/0x164
    ? dma_virt_map_sg+0x22c/0x22c
    ubsan_epilogue+0xe/0x81
    __ubsan_handle_shift_out_of_bounds+0x293/0x2f7
    ? debug_check_no_locks_freed+0x340/0x340
    ? __ubsan_handle_load_invalid_value+0x19b/0x19b
    ? lock_acquire+0x440/0x440
    ? lock_acquire+0x19d/0x440
    ? __might_fault+0xf4/0x240
    ? ib_uverbs_write+0x68d/0xe20
    ib_uverbs_write+0x68d/0xe20
    ? __lock_acquire+0xcf7/0x3940
    ? uverbs_devnode+0x110/0x110
    ? cyc2ns_read_end+0x10/0x10
    ? sched_clock_cpu+0x18/0x200
    ? sched_clock_cpu+0x18/0x200
    __vfs_write+0x10d/0x700
    ? uverbs_devnode+0x110/0x110
    ? kernel_read+0x170/0x170
    ? __fget+0x35b/0x5d0
    ? security_file_permission+0x93/0x260
    vfs_write+0x1b0/0x550
    SyS_write+0xc7/0x1a0
    ? SyS_read+0x1a0/0x1a0
    ? trace_hardirqs_on_thunk+0x1a/0x1c
    entry_SYSCALL_64_fastpath+0x18/0x85
    RIP: 0033:0x448e29
    RSP: 002b:00007f033f567c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 00007f033f5686bc RCX: 0000000000448e29
    RDX: 0000000000000060 RSI: 0000000020001000 RDI: 0000000000000012
    RBP: 000000000070bea0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
    R13: 00000000000056a0 R14: 00000000006e8740 R15: 0000000000000000
    ================================================================================
    
    Cc: syzkaller <syzkaller@googlegroups.com>
    Cc: <stable@vger.kernel.org> # 4.5
    Fixes: 2dbd5186a39c ("IB/core: IB/core: Allow legacy verbs through extended interfaces")
    Reported-by: Noa Osherovich <noaos@mellanox.com>
    Reviewed-by: Matan Barak <matanb@mellanox.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4b02ca6149773f86af266e75a0e69c374bb90ed
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Feb 22 14:38:33 2018 +0000

    PKCS#7: fix certificate chain verification
    
    commit 971b42c038dc83e3327872d294fe7131bab152fc upstream.
    
    When pkcs7_verify_sig_chain() is building the certificate chain for a
    SignerInfo using the certificates in the PKCS#7 message, it is passing
    the wrong arguments to public_key_verify_signature().  Consequently,
    when the next certificate is supposed to be used to verify the previous
    certificate, the next certificate is actually used to verify itself.
    
    An attacker can use this bug to create a bogus certificate chain that
    has no cryptographic relationship between the beginning and end.
    
    Fortunately I couldn't quite find a way to use this to bypass the
    overall signature verification, though it comes very close.  Here's the
    reasoning: due to the bug, every certificate in the chain beyond the
    first actually has to be self-signed (where "self-signed" here refers to
    the actual key and signature; an attacker might still manipulate the
    certificate fields such that the self_signed flag doesn't actually get
    set, and thus the chain doesn't end immediately).  But to pass trust
    validation (pkcs7_validate_trust()), either the SignerInfo or one of the
    certificates has to actually be signed by a trusted key.  Since only
    self-signed certificates can be added to the chain, the only way for an
    attacker to introduce a trusted signature is to include a self-signed
    trusted certificate.
    
    But, when pkcs7_validate_trust_one() reaches that certificate, instead
    of trying to verify the signature on that certificate, it will actually
    look up the corresponding trusted key, which will succeed, and then try
    to verify the *previous* certificate, which will fail.  Thus, disaster
    is narrowly averted (as far as I could tell).
    
    Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier")
    Cc: <stable@vger.kernel.org> # v4.7+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c60e246f56738036a4962b0aa40ff7ffbad6ec5f
Author: Eric Biggers <ebiggers@google.com>
Date:   Thu Feb 22 14:38:33 2018 +0000

    X.509: fix BUG_ON() when hash algorithm is unsupported
    
    commit 437499eea4291ae9621e8763a41df027c110a1ef upstream.
    
    The X.509 parser mishandles the case where the certificate's signature's
    hash algorithm is not available in the crypto API.  In this case,
    x509_get_sig_params() doesn't allocate the cert->sig->digest buffer;
    this part seems to be intentional.  However,
    public_key_verify_signature() is still called via
    x509_check_for_self_signed(), which triggers the 'BUG_ON(!sig->digest)'.
    
    Fix this by making public_key_verify_signature() return -ENOPKG if the
    hash buffer has not been allocated.
    
    Reproducer when all the CONFIG_CRYPTO_SHA512* options are disabled:
    
        openssl req -new -sha512 -x509 -batch -nodes -outform der \
            | keyctl padd asymmetric desc @s
    
    Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier")
    Reported-by: Paolo Valente <paolo.valente@linaro.org>
    Cc: Paolo Valente <paolo.valente@linaro.org>
    Cc: <stable@vger.kernel.org> # v4.7+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b4dd8ac6b4f957e8e4b0434bb4cff724615e9e6
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 2 16:31:23 2018 +0100

    cfg80211: fix cfg80211_beacon_dup
    
    commit bee92d06157fc39d5d7836a061c7d41289a55797 upstream.
    
    gcc-8 warns about some obviously incorrect code:
    
    net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
    net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
    
    From the context, I conclude that we want to copy from beacon into
    new_beacon, as we do in the rest of the function.
    
    Cc: stable@vger.kernel.org
    Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bed7cb3191699212ea84cdbc35232492682ae27e
Author: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date:   Tue Jan 23 20:11:32 2018 -0600

    scsi: ibmvfc: fix misdefined reserved field in ibmvfc_fcp_rsp_info
    
    commit c39813652700f3df552b6557530f1e5f782dbe2f upstream.
    
    The fcp_rsp_info structure as defined in the FC spec has an initial 3
    bytes reserved field. The ibmvfc driver mistakenly defined this field as
    4 bytes resulting in the rsp_code field being defined in what should be
    the start of the second reserved field and thus always being reported as
    zero by the driver.
    
    Ideally, we should wire ibmvfc up with libfc for the sake of code
    deduplication, and ease of maintaining standardized structures in a
    single place. However, for now simply fixup the definition in ibmvfc for
    backporting to distros on older kernels. Wiring up with libfc will be
    done in a followup patch.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5ecf56cb25462c07afabeee1ba12e09cd8484bd
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Tue Feb 13 15:31:05 2018 -0800

    xtensa: fix high memory/reserved memory collision
    
    commit 6ac5a11dc674bc5016ea716e8082fff61f524dc1 upstream.
    
    Xtensa memory initialization code frees high memory pages without
    checking whether they are in the reserved memory regions or not. That
    results in invalid value of totalram_pages and duplicate page usage by
    CMA and highmem. It produces a bunch of BUGs at startup looking like
    this:
    
    BUG: Bad page state in process swapper  pfn:70800
    page:be60c000 count:0 mapcount:-127 mapping:  (null) index:0x1
    flags: 0x80000000()
    raw: 80000000 00000000 00000001 ffffff80 00000000 be60c014 be60c014 0000000a
    page dumped because: nonzero mapcount
    Modules linked in:
    CPU: 0 PID: 1 Comm: swapper Tainted: G    B            4.16.0-rc1-00015-g7928b2cbe55b-dirty #23
    Stack:
     bd839d33 00000000 00000018 ba97b64c a106578c bd839d70 be60c000 00000000
     a1378054 bd86a000 00000003 ba97b64c a1066166 bd839da0 be60c000 ffe00000
     a1066b58 bd839dc0 be504000 00000000 000002f4 bd838000 00000000 0000001e
    Call Trace:
     [<a1065734>] bad_page+0xac/0xd0
     [<a106578c>] free_pages_check_bad+0x34/0x4c
     [<a1066166>] __free_pages_ok+0xae/0x14c
     [<a1066b58>] __free_pages+0x30/0x64
     [<a1365de5>] init_cma_reserved_pageblock+0x35/0x44
     [<a13682dc>] cma_init_reserved_areas+0xf4/0x148
     [<a10034b8>] do_one_initcall+0x80/0xf8
     [<a1361c16>] kernel_init_freeable+0xda/0x13c
     [<a125b59d>] kernel_init+0x9/0xd0
     [<a1004304>] ret_from_kernel_thread+0xc/0x18
    
    Only free high memory pages that are not reserved.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d58d78c207a348a87cb143dadcbf839ea35443b6
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Feb 8 12:19:00 2018 +0100

    netfilter: drop outermost socket lock in getsockopt()
    
    commit 01ea306f2ac2baff98d472da719193e738759d93 upstream.
    
    The Syzbot reported a possible deadlock in the netfilter area caused by
    rtnl lock, xt lock and socket lock being acquired with a different order
    on different code paths, leading to the following backtrace:
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    
    ======================================================
    WARNING: possible circular locking dependency detected
    4.15.0+ #301 Not tainted
    ------------------------------------------------------
    syzkaller233489/4179 is trying to acquire lock:
      (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20
    net/core/rtnetlink.c:74
    
    but task is already holding lock:
      (&xt[i].mutex){+.+.}, at: [<00000000328553a2>]
    xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041
    
    which lock already depends on the new lock.
    ===
    
    Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock
    only in the required scope"), we already acquire the socket lock in
    the innermost scope, where needed. In such commit I forgot to remove
    the outer-most socket lock from the getsockopt() path, this commit
    addresses the issues dropping it now.
    
    v1 -> v2: fix bad subj, added relavant 'fixes' tag
    
    Fixes: 22265a5c3c10 ("netfilter: xt_TEE: resolve oif using netdevice notifiers")
    Fixes: 202f59afd441 ("netfilter: ipt_CLUSTERIP: do not hold dev")
    Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope")
    Reported-by: syzbot+ddde1c7b7ff7442d7f2d@syzkaller.appspotmail.com
    Suggested-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>