commit ffc97d4dde1d3c77beebddbbd2a0be5f8f18236a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Oct 5 09:36:10 2017 +0200

    Linux 3.18.73

commit 376c6f62f8d4f73a0573a0e69323afe39d834893
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Oct 4 15:51:29 2017 +0200

    fix xen_swiotlb_dma_mmap prototype
    
    xen_swiotlb_dma_mmap was backported from v4.10, but older
    kernels before commit 00085f1efa38 ("dma-mapping: use unsigned long
    for dma_attrs") use a different signature:
    
    arm/xen/mm.c:202:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
      .mmap = xen_swiotlb_dma_mmap,
              ^~~~~~~~~~~~~~~~~~~~
    arm/xen/mm.c:202:10: note: (near initialization for 'xen_swiotlb_dma_ops.mmap')
    
    This adapts the patch to the old calling conventions.
    
    Fixes: "swiotlb-xen: implement xen_swiotlb_dma_mmap callback"
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bc9f6868dfb50ba357d4db5916632c94f8d94a4c
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Feb 7 19:58:02 2017 +0200

    swiotlb-xen: implement xen_swiotlb_dma_mmap callback
    
    commit 7e91c7df29b5e196de3dc6f086c8937973bd0b88 upstream.
    
    This function creates userspace mapping for the DMA-coherent memory.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
    Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d53f0b14066d798104411f13442afc20bdea4d6
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Mon Sep 4 16:00:50 2017 +0200

    video: fbdev: aty: do not leak uninitialized padding in clk to userspace
    
    commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.
    
    'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
    field unitialized, leaking data from the stack. Fix this ensuring all of
    'clk' is initialized to zero.
    
    References: https://github.com/torvalds/linux/pull/441
    Reported-by: sohu0106 <sohu0106@126.com>
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f23ec06d527c9cd90552a68c748bcb5aa942ee87
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Oct 2 11:10:07 2017 -0700

    x86/fpu: Don't let userspace set bogus xcomp_bv
    
    commit 814fb7bb7db5433757d76f4c4502c96fc53b0b5e upstream.
    
    [Please apply to 3.18-stable.  Note: the backport includes the
    fpu_finit() call in xstateregs_set(), since fix is useless without it.
    It was added by commit 91c3dba7dbc1 ("x86/fpu/xstate: Fix PTRACE frames
    for XSAVES"), but it doesn't make sense to backport that whole commit.]
    
    On x86, userspace can use the ptrace() or rt_sigreturn() system calls to
    set a task's extended state (xstate) or "FPU" registers.  ptrace() can
    set them for another task using the PTRACE_SETREGSET request with
    NT_X86_XSTATE, while rt_sigreturn() can set them for the current task.
    In either case, registers can be set to any value, but the kernel
    assumes that the XSAVE area itself remains valid in the sense that the
    CPU can restore it.
    
    However, in the case where the kernel is using the uncompacted xstate
    format (which it does whenever the XSAVES instruction is unavailable),
    it was possible for userspace to set the xcomp_bv field in the
    xstate_header to an arbitrary value.  However, all bits in that field
    are reserved in the uncompacted case, so when switching to a task with
    nonzero xcomp_bv, the XRSTOR instruction failed with a #GP fault.  This
    caused the WARN_ON_FPU(err) in copy_kernel_to_xregs() to be hit.  In
    addition, since the error is otherwise ignored, the FPU registers from
    the task previously executing on the CPU were leaked.
    
    Fix the bug by checking that the user-supplied value of xcomp_bv is 0 in
    the uncompacted case, and returning an error otherwise.
    
    The reason for validating xcomp_bv rather than simply overwriting it
    with 0 is that we want userspace to see an error if it (incorrectly)
    provides an XSAVE area in compacted format rather than in uncompacted
    format.
    
    Note that as before, in case of error we clear the task's FPU state.
    This is perhaps non-ideal, especially for PTRACE_SETREGSET; it might be
    better to return an error before changing anything.  But it seems the
    "clear on error" behavior is fine for now, and it's a little tricky to
    do otherwise because it would mean we couldn't simply copy the full
    userspace state into kernel memory in one __copy_from_user().
    
    This bug was found by syzkaller, which hit the above-mentioned
    WARN_ON_FPU():
    
        WARNING: CPU: 1 PID: 0 at ./arch/x86/include/asm/fpu/internal.h:373 __switch_to+0x5b5/0x5d0
        CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.13.0 #453
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        task: ffff9ba2bc8e42c0 task.stack: ffffa78cc036c000
        RIP: 0010:__switch_to+0x5b5/0x5d0
        RSP: 0000:ffffa78cc08bbb88 EFLAGS: 00010082
        RAX: 00000000fffffffe RBX: ffff9ba2b8bf2180 RCX: 00000000c0000100
        RDX: 00000000ffffffff RSI: 000000005cb10700 RDI: ffff9ba2b8bf36c0
        RBP: ffffa78cc08bbbd0 R08: 00000000929fdf46 R09: 0000000000000001
        R10: 0000000000000000 R11: 0000000000000000 R12: ffff9ba2bc8e42c0
        R13: 0000000000000000 R14: ffff9ba2b8bf3680 R15: ffff9ba2bf5d7b40
        FS:  00007f7e5cb10700(0000) GS:ffff9ba2bf400000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00000000004005cc CR3: 0000000079fd5000 CR4: 00000000001406e0
        Call Trace:
        Code: 84 00 00 00 00 00 e9 11 fd ff ff 0f ff 66 0f 1f 84 00 00 00 00 00 e9 e7 fa ff ff 0f ff 66 0f 1f 84 00 00 00 00 00 e9 c2 fa ff ff <0f> ff 66 0f 1f 84 00 00 00 00 00 e9 d4 fc ff ff 66 66 2e 0f 1f
    
    Here is a C reproducer.  The expected behavior is that the program spin
    forever with no output.  However, on a buggy kernel running on a
    processor with the "xsave" feature but without the "xsaves" feature
    (e.g. Sandy Bridge through Broadwell for Intel), within a second or two
    the program reports that the xmm registers were corrupted, i.e. were not
    restored correctly.  With CONFIG_X86_DEBUG_FPU=y it also hits the above
    kernel warning.
    
        #define _GNU_SOURCE
        #include <stdbool.h>
        #include <inttypes.h>
        #include <linux/elf.h>
        #include <stdio.h>
        #include <sys/ptrace.h>
        #include <sys/uio.h>
        #include <sys/wait.h>
        #include <unistd.h>
    
        int main(void)
        {
            int pid = fork();
            uint64_t xstate[512];
            struct iovec iov = { .iov_base = xstate, .iov_len = sizeof(xstate) };
    
            if (pid == 0) {
                bool tracee = true;
                for (int i = 0; i < sysconf(_SC_NPROCESSORS_ONLN) && tracee; i++)
                    tracee = (fork() != 0);
                uint32_t xmm0[4] = { [0 ... 3] = tracee ? 0x00000000 : 0xDEADBEEF };
                asm volatile("   movdqu %0, %%xmm0\n"
                             "   mov %0, %%rbx\n"
                             "1: movdqu %%xmm0, %0\n"
                             "   mov %0, %%rax\n"
                             "   cmp %%rax, %%rbx\n"
                             "   je 1b\n"
                             : "+m" (xmm0) : : "rax", "rbx", "xmm0");
                printf("BUG: xmm registers corrupted!  tracee=%d, xmm0=%08X%08X%08X%08X\n",
                       tracee, xmm0[0], xmm0[1], xmm0[2], xmm0[3]);
            } else {
                usleep(100000);
                ptrace(PTRACE_ATTACH, pid, 0, 0);
                wait(NULL);
                ptrace(PTRACE_GETREGSET, pid, NT_X86_XSTATE, &iov);
                xstate[65] = -1;
                ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, &iov);
                ptrace(PTRACE_CONT, pid, 0, 0);
                wait(NULL);
            }
            return 1;
        }
    
    Note: the program only tests for the bug using the ptrace() system call.
    The bug can also be reproduced using the rt_sigreturn() system call, but
    only when called from a 32-bit program, since for 64-bit programs the
    kernel restores the FPU state from the signal frame by doing XRSTOR
    directly from userspace memory (with proper error checking).
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Eric Biggers <ebiggers3@gmail.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Kevin Hao <haokexin@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Michael Halcrow <mhalcrow@google.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Wanpeng Li <wanpeng.li@hotmail.com>
    Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>
    Cc: kernel-hardening@lists.openwall.com
    Fixes: 0b29643a5843 ("x86/xsaves: Change compacted format xsave area header")
    Link: http://lkml.kernel.org/r/20170922174156.16780-2-ebiggers3@gmail.com
    Link: http://lkml.kernel.org/r/20170923130016.21448-25-mingo@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 540125645c70c02e485365a259545a15571e863a
Author: satoru takeuchi <satoru.takeuchi@gmail.com>
Date:   Tue Sep 12 22:42:52 2017 +0900

    btrfs: prevent to set invalid default subvolid
    
    commit 6d6d282932d1a609e60dc4467677e0e863682f57 upstream.
    
    `btrfs sub set-default` succeeds to set an ID which isn't corresponding to any
    fs/file tree. If such the bad ID is set to a filesystem, we can't mount this
    filesystem without specifying `subvol` or `subvolid` mount options.
    
    Fixes: 6ef5ed0d386b ("Btrfs: add ioctl and incompat flag to set the default mount subvol")
    Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
    Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0544aab81d35a0ec852eb63a5e6bfa6eac132848
Author: Nicolai Stange <nstange@suse.de>
Date:   Mon Sep 11 09:45:40 2017 +0200

    PCI: Fix race condition with driver_override
    
    commit 9561475db680f7144d2223a409dd3d7e322aca03 upstream.
    
    The driver_override implementation is susceptible to a race condition when
    different threads are reading vs. storing a different driver override.  Add
    locking to avoid the race condition.
    
    This is in close analogy to commit 6265539776a0 ("driver core: platform:
    fix race condition with driver_override") from Adrian Salido.
    
    Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override")
    Signed-off-by: Nicolai Stange <nstange@suse.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ad74630c016ef823f2720671ee4db641d35fd2c
Author: Jim Mattson <jmattson@google.com>
Date:   Tue Sep 12 13:02:54 2017 -0700

    kvm: nVMX: Don't allow L2 to access the hardware CR8
    
    commit 51aa68e7d57e3217192d88ce90fd5b8ef29ec94f upstream.
    
    If L1 does not specify the "use TPR shadow" VM-execution control in
    vmcs12, then L0 must specify the "CR8-load exiting" and "CR8-store
    exiting" VM-execution controls in vmcs02. Failure to do so will give
    the L2 VM unrestricted read/write access to the hardware CR8.
    
    This fixes CVE-2017-12154.
    
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6528968794bc6b4091a7603ae863472c1ef7c393
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Sep 26 15:57:16 2017 +0100

    arm64: Make sure SPsel is always set
    
    commit 5371513fb338fb9989c569dc071326d369d6ade8 upstream.
    
    When the kernel is entered at EL2 on an ARMv8.0 system, we construct
    the EL1 pstate and make sure this uses the the EL1 stack pointer
    (we perform an exception return to EL1h).
    
    But if the kernel is either entered at EL1 or stays at EL2 (because
    we're on a VHE-capable system), we fail to set SPsel, and use whatever
    stack selection the higher exception level has choosen for us.
    
    Let's not take any chance, and make sure that SPsel is set to one
    before we decide the mode we're going to run in.
    
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d9100405a20a71dd620843e0380e38fc50731108
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Sep 7 13:54:35 2017 +0200

    bsg-lib: don't free job in bsg_prepare_job
    
    commit f507b54dccfd8000c517d740bc45f20c74532d18 upstream.
    
    The job structure is allocated as part of the request, so we should not
    free it in the error path of bsg_prepare_job.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65e3664fc6087d2941e940e38beb39920e9ae032
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Wed Sep 13 00:21:21 2017 +0200

    nl80211: check for the required netlink attributes presence
    
    commit e785fa0a164aa11001cba931367c7f94ffaff888 upstream.
    
    nl80211_set_rekey_data() does not check if the required attributes
    NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing
    NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by
    users with CAP_NET_ADMIN privilege and may result in NULL dereference
    and a system crash. Add a check for the required attributes presence.
    This patch is based on the patch by bo Zhang.
    
    This fixes CVE-2017-12153.
    
    References: https://bugzilla.redhat.com/show_bug.cgi?id=1491046
    Fixes: e5497d766ad ("cfg80211/nl80211: support GTK rekey offload")
    Reported-by: bo Zhang <zhangbo5891001@gmail.com>
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9f119f5cc0480e7d1eaa4e16ecbcddcdd5e8db6f
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Mon Sep 25 12:23:03 2017 +0200

    vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets
    
    commit fc46820b27a2d9a46f7e90c9ceb4a64a1bc5fab8 upstream.
    
    In generic_file_llseek_size, return -ENXIO for negative offsets as well
    as offsets beyond EOF.  This affects filesystems which don't implement
    SEEK_HOLE / SEEK_DATA internally, possibly because they don't support
    holes.
    
    Fixes xfstest generic/448.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64304f5ae2f37d54072b208d53fb692ef941d168
Author: Steve French <smfrench@gmail.com>
Date:   Fri Sep 22 01:40:27 2017 -0500

    SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags
    
    commit 1013e760d10e614dc10b5624ce9fc41563ba2e65 upstream.
    
    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b3c1243ba1bc4ab4c632078412381750f94bb649
Author: Steve French <smfrench@gmail.com>
Date:   Wed Sep 20 19:57:18 2017 -0500

    SMB: Validate negotiate (to protect against downgrade) even if signing off
    
    commit 0603c96f3af50e2f9299fa410c224ab1d465e0f9 upstream.
    
    As long as signing is supported (ie not a guest user connection) and
    connection is SMB3 or SMB3.02, then validate negotiate (protect
    against man in the middle downgrade attacks).  We had been doing this
    only when signing was required, not when signing was just enabled,
    but this more closely matches recommended SMB3 behavior and is
    better security.  Suggested by Metze.
    
    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Jeremy Allison <jra@samba.org>
    Acked-by: Stefan Metzmacher <metze@samba.org>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b93becabbaf4c0e3963ebd62e2e094fc68deec08
Author: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date:   Wed Sep 20 17:02:52 2017 -0400

    powerpc/pseries: Fix parent_dn reference leak in add_dt_node()
    
    commit b537ca6fede69a281dc524983e5e633d79a10a08 upstream.
    
    A reference to the parent device node is held by add_dt_node() for the
    node to be added. If the call to dlpar_configure_connector() fails
    add_dt_node() returns ENOENT and that reference is not freed.
    
    Add a call to of_node_put(parent_dn) prior to bailing out after a
    failed dlpar_configure_connector() call.
    
    Fixes: 8d5ff320766f ("powerpc/pseries: Make dlpar_configure_connector parent node aware")
    Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ea8051f42d965e3197ef31d4f54f75525b9439c
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Sep 18 11:37:23 2017 -0700

    KEYS: prevent KEYCTL_READ on negative key
    
    commit 37863c43b2c6464f252862bf2e9768264e961678 upstream.
    
    Because keyctl_read_key() looks up the key with no permissions
    requested, it may find a negatively instantiated key.  If the key is
    also possessed, we went ahead and called ->read() on the key.  But the
    key payload will actually contain the ->reject_error rather than the
    normal payload.  Thus, the kernel oopses trying to read the
    user_key_payload from memory address (int)-ENOKEY = 0x00000000ffffff82.
    
    Fortunately the payload data is stored inline, so it shouldn't be
    possible to abuse this as an arbitrary memory read primitive...
    
    Reproducer:
        keyctl new_session
        keyctl request2 user desc '' @s
        keyctl read $(keyctl show | awk '/user: desc/ {print $1}')
    
    It causes a crash like the following:
         BUG: unable to handle kernel paging request at 00000000ffffff92
         IP: user_read+0x33/0xa0
         PGD 36a54067 P4D 36a54067 PUD 0
         Oops: 0000 [#1] SMP
         CPU: 0 PID: 211 Comm: keyctl Not tainted 4.14.0-rc1 #337
         Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
         task: ffff90aa3b74c3c0 task.stack: ffff9878c0478000
         RIP: 0010:user_read+0x33/0xa0
         RSP: 0018:ffff9878c047bee8 EFLAGS: 00010246
         RAX: 0000000000000001 RBX: ffff90aa3d7da340 RCX: 0000000000000017
         RDX: 0000000000000000 RSI: 00000000ffffff82 RDI: ffff90aa3d7da340
         RBP: ffff9878c047bf00 R08: 00000024f95da94f R09: 0000000000000000
         R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
         R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
         FS:  00007f58ece69740(0000) GS:ffff90aa3e200000(0000) knlGS:0000000000000000
         CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         CR2: 00000000ffffff92 CR3: 0000000036adc001 CR4: 00000000003606f0
         Call Trace:
          keyctl_read_key+0xac/0xe0
          SyS_keyctl+0x99/0x120
          entry_SYSCALL_64_fastpath+0x1f/0xbe
         RIP: 0033:0x7f58ec787bb9
         RSP: 002b:00007ffc8d401678 EFLAGS: 00000206 ORIG_RAX: 00000000000000fa
         RAX: ffffffffffffffda RBX: 00007ffc8d402800 RCX: 00007f58ec787bb9
         RDX: 0000000000000000 RSI: 00000000174a63ac RDI: 000000000000000b
         RBP: 0000000000000004 R08: 00007ffc8d402809 R09: 0000000000000020
         R10: 0000000000000000 R11: 0000000000000206 R12: 00007ffc8d402800
         R13: 00007ffc8d4016e0 R14: 0000000000000000 R15: 0000000000000000
         Code: e5 41 55 49 89 f5 41 54 49 89 d4 53 48 89 fb e8 a4 b4 ad ff 85 c0 74 09 80 3d b9 4c 96 00 00 74 43 48 8b b3 20 01 00 00 4d 85 ed <0f> b7 5e 10 74 29 4d 85 e4 74 24 4c 39 e3 4c 89 e2 4c 89 ef 48
         RIP: user_read+0x33/0xa0 RSP: ffff9878c047bee8
         CR2: 00000000ffffff92
    
    Fixes: 61ea0c0ba904 ("KEYS: Skip key state checks when checking for possession")
    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 e3b663ba2ddd8f30ba92d4e6898637bb526dba70
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Sep 18 11:37:03 2017 -0700

    KEYS: prevent creating a different user's keyrings
    
    commit 237bbd29f7a049d310d907f4b2716a7feef9abf3 upstream.
    
    It was possible for an unprivileged user to create the user and user
    session keyrings for another user.  For example:
    
        sudo -u '#3000' sh -c 'keyctl add keyring _uid.4000 "" @u
                               keyctl add keyring _uid_ses.4000 "" @u
                               sleep 15' &
        sleep 1
        sudo -u '#4000' keyctl describe @u
        sudo -u '#4000' keyctl describe @us
    
    This is problematic because these "fake" keyrings won't have the right
    permissions.  In particular, the user who created them first will own
    them and will have full access to them via the possessor permissions,
    which can be used to compromise the security of a user's keys:
    
        -4: alswrv-----v------------  3000     0 keyring: _uid.4000
        -5: alswrv-----v------------  3000     0 keyring: _uid_ses.4000
    
    Fix it by marking user and user session keyrings with a flag
    KEY_FLAG_UID_KEYRING.  Then, when searching for a user or user session
    keyring by name, skip all keyrings that don't have the flag set.
    
    Fixes: 69664cf16af4 ("keys: don't generate user and user session keyrings unless they're accessed")
    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 50f17a4b9141111a50d9eb127389fa69b2085d7c
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Sep 18 11:36:45 2017 -0700

    KEYS: fix writing past end of user-supplied buffer in keyring_read()
    
    commit e645016abc803dafc75e4b8f6e4118f088900ffb upstream.
    
    Userspace can call keyctl_read() on a keyring to get the list of IDs of
    keys in the keyring.  But if the user-supplied buffer is too small, the
    kernel would write the full list anyway --- which will corrupt whatever
    userspace memory happened to be past the end of the buffer.  Fix it by
    only filling the space that is available.
    
    Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
    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 2d9db72fb50e72aafaac2b99f4fcf1013497d8da
Author: LEROY Christophe <christophe.leroy@c-s.fr>
Date:   Wed Sep 13 12:44:51 2017 +0200

    crypto: talitos - fix sha224
    
    commit afd62fa26343be6445479e75de9f07092a061459 upstream.
    
    Kernel crypto tests report the following error at startup
    
    [    2.752626] alg: hash: Test 4 failed for sha224-talitos
    [    2.757907] 00000000: 30 e2 86 e2 e7 8a dd 0d d7 eb 9f d5 83 fe f1 b0
    00000010: 2d 5a 6c a5 f9 55 ea fd 0e 72 05 22
    
    This patch fixes it
    
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fec4cd33779f9edd7ab2d0d5ad7228f55f3f6887
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sun Aug 27 20:25:26 2017 +0800

    scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly
    
    commit c88f0e6b06f4092995688211a631bb436125d77b upstream.
    
    ChunYu found a kernel crash by syzkaller:
    
    [  651.617875] kasan: CONFIG_KASAN_INLINE enabled
    [  651.618217] kasan: GPF could be caused by NULL-ptr deref or user memory access
    [  651.618731] general protection fault: 0000 [#1] SMP KASAN
    [  651.621543] CPU: 1 PID: 9539 Comm: scsi Not tainted 4.11.0.cov #32
    [  651.621938] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    [  651.622309] task: ffff880117780000 task.stack: ffff8800a3188000
    [  651.622762] RIP: 0010:skb_release_data+0x26c/0x590
    [...]
    [  651.627260] Call Trace:
    [  651.629156]  skb_release_all+0x4f/0x60
    [  651.629450]  consume_skb+0x1a5/0x600
    [  651.630705]  netlink_unicast+0x505/0x720
    [  651.632345]  netlink_sendmsg+0xab2/0xe70
    [  651.633704]  sock_sendmsg+0xcf/0x110
    [  651.633942]  ___sys_sendmsg+0x833/0x980
    [  651.637117]  __sys_sendmsg+0xf3/0x240
    [  651.638820]  SyS_sendmsg+0x32/0x50
    [  651.639048]  entry_SYSCALL_64_fastpath+0x1f/0xc2
    
    It's caused by skb_shared_info at the end of sk_buff was overwritten by
    ISCSI_KEVENT_IF_ERROR when parsing nlmsg info from skb in iscsi_if_rx.
    
    During the loop if skb->len == nlh->nlmsg_len and both are sizeof(*nlh),
    ev = nlmsg_data(nlh) will acutally get skb_shinfo(SKB) instead and set a
    new value to skb_shinfo(SKB)->nr_frags by ev->type.
    
    This patch is to fix it by checking nlh->nlmsg_len properly there to
    avoid over accessing sk_buff.
    
    Reported-by: ChunYu Wang <chunwang@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Chris Leech <cleech@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 58061248504a4ab93f802e648daad063857dcac6
Author: Bo Yan <byan@nvidia.com>
Date:   Mon Sep 18 10:03:35 2017 -0700

    tracing: Erase irqsoff trace with empty write
    
    commit 8dd33bcb7050dd6f8c1432732f930932c9d3a33e upstream.
    
    One convenient way to erase trace is "echo > trace". However, this
    is currently broken if the current tracer is irqsoff tracer. This
    is because irqsoff tracer use max_buffer as the default trace
    buffer.
    
    Set the max_buffer as the one to be cleared when it's the trace
    buffer currently in use.
    
    Link: http://lkml.kernel.org/r/1505754215-29411-1-git-send-email-byan@nvidia.com
    
    Cc: <mingo@redhat.com>
    Fixes: 4acd4d00f ("tracing: give easy way to clear trace buffer")
    Signed-off-by: Bo Yan <byan@nvidia.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8923bf76c1ea47b16b2d6ccb9e09cdd913ffa06d
Author: Tahsin Erdogan <tahsin@google.com>
Date:   Sun Sep 17 03:23:48 2017 -0700

    tracing: Fix trace_pipe behavior for instance traces
    
    commit 75df6e688ccd517e339a7c422ef7ad73045b18a2 upstream.
    
    When reading data from trace_pipe, tracing_wait_pipe() performs a
    check to see if tracing has been turned off after some data was read.
    Currently, this check always looks at global trace state, but it
    should be checking the trace instance where trace_pipe is located at.
    
    Because of this bug, cat instances/i1/trace_pipe in the following
    script will immediately exit instead of waiting for data:
    
    cd /sys/kernel/debug/tracing
    echo 0 > tracing_on
    mkdir -p instances/i1
    echo 1 > instances/i1/tracing_on
    echo 1 > instances/i1/events/sched/sched_process_exec/enable
    cat instances/i1/trace_pipe
    
    Link: http://lkml.kernel.org/r/20170917102348.1615-1-tahsin@google.com
    
    Fixes: 10246fa35d4f ("tracing: give easy way to clear trace buffer")
    Signed-off-by: Tahsin Erdogan <tahsin@google.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b9ce7484a5f7099435ee2827acd1020edacedef
Author: Paul Mackerras <paulus@ozlabs.org>
Date:   Tue Sep 12 16:00:24 2017 +1000

    KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce()
    
    commit 47c5310a8dbe7c2cb9f0083daa43ceed76c257fa upstream, with part
    of commit edd03602d97236e8fea13cd76886c576186aa307 folded in.
    
    Nixiaoming pointed out that there is a memory leak in
    kvm_vm_ioctl_create_spapr_tce() if the call to anon_inode_getfd()
    fails; the memory allocated for the kvmppc_spapr_tce_table struct
    is not freed, and nor are the pages allocated for the iommu
    tables.
    
    David Hildenbrand pointed out that there is a race in that the
    function checks early on that there is not already an entry in the
    stt->iommu_tables list with the same LIOBN, but an entry with the
    same LIOBN could get added between then and when the new entry is
    added to the list.
    
    This fixes both problems.  To simplify things, we now call
    anon_inode_getfd() before placing the new entry in the list.  The
    check for an existing entry is done while holding the kvm->lock
    mutex, immediately before adding the new entry to the list.
    
    [paulus@ozlabs.org - folded in that part of edd03602d972 ("KVM:
     PPC: Book3S HV: Protect updates to spapr_tce_tables list", 2017-08-28)
     which restructured the code that 47c5310a8dbe modified, to avoid
     a build failure caused by the absence of put_unused_fd().
     Also removed the locked memory accounting, since it doesn't exist
     in this version, and adjusted the commit message.]
    
    Fixes: 54738c097163 ("KVM: PPC: Accelerate H_PUT_TCE by implementing it in real mode")
    Reported-by: Nixiaoming <nixiaoming@huawei.com>
    Reported-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 998173c7a119102c637506b5ecaa205821755a65
Author: Avraham Stern <avraham.stern@intel.com>
Date:   Fri Aug 18 15:33:57 2017 +0300

    mac80211: flush hw_roc_start work before cancelling the ROC
    
    commit 6e46d8ce894374fc135c96a8d1057c6af1fef237 upstream.
    
    When HW ROC is supported it is possible that after the HW notified
    that the ROC has started, the ROC was cancelled and another ROC was
    added while the hw_roc_start worker is waiting on the mutex (since
    cancelling the ROC and adding another one also holds the same mutex).
    As a result, the hw_roc_start worker will continue to run after the
    new ROC is added but before it is actually started by the HW.
    This may result in notifying userspace that the ROC has started before
    it actually does, or in case of management tx ROC, in an attempt to
    tx while not on the right channel.
    
    In addition, when the driver will notify mac80211 that the second ROC
    has started, mac80211 will warn that this ROC has already been
    notified.
    
    Fix this by flushing the hw_roc_start work before cancelling an ROC.
    
    Signed-off-by: Avraham Stern <avraham.stern@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 456bbdc86d18d95d389cc8012259176c09211d5b
Author: Shu Wang <shuwang@redhat.com>
Date:   Fri Sep 8 18:48:33 2017 +0800

    cifs: release auth_key.response for reconnect.
    
    commit f5c4ba816315d3b813af16f5571f86c8d4e897bd upstream.
    
    There is a race that cause cifs reconnect in cifs_mount,
    - cifs_mount
      - cifs_get_tcp_session
        - [ start thread cifs_demultiplex_thread
          - cifs_read_from_socket: -ECONNABORTED
            - DELAY_WORK smb2_reconnect_server ]
      - cifs_setup_session
      - [ smb2_reconnect_server ]
    
    auth_key.response was allocated in cifs_setup_session, and
    will release when the session destoried. So when session re-
    connect, auth_key.response should be check and released.
    
    Tested with my system:
    CIFS VFS: Free previous auth_key.response = ffff8800320bbf80
    
    A simple auth_key.response allocation call trace:
    - cifs_setup_session
    - SMB2_sess_setup
    - SMB2_sess_auth_rawntlmssp_authenticate
    - build_ntlmssp_auth_blob
    - setup_ntlmv2_rsp
    
    Signed-off-by: Shu Wang <shuwang@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c317759e7805e8a615e076186108754093e6d68
Author: Shu Wang <shuwang@redhat.com>
Date:   Thu Sep 7 16:03:27 2017 +0800

    cifs: release cifs root_cred after exit_cifs
    
    commit 94183331e815617246b1baa97e0916f358c794bb upstream.
    
    memory leak was found by kmemleak. exit_cifs_spnego
    should be called before cifs module removed, or
    cifs root_cred will not be released.
    
    kmemleak report:
    unreferenced object 0xffff880070a3ce40 (size 192):
      backtrace:
         kmemleak_alloc+0x4a/0xa0
         kmem_cache_alloc+0xc7/0x1d0
         prepare_kernel_cred+0x20/0x120
         init_cifs_spnego+0x2d/0x170 [cifs]
         0xffffffffc07801f3
         do_one_initcall+0x51/0x1b0
         do_init_module+0x60/0x1fd
         load_module+0x161e/0x1b60
         SYSC_finit_module+0xa9/0x100
         SyS_finit_module+0xe/0x10
    
    Signed-off-by: Shu Wang <shuwang@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>