1. 05 Sep, 2018 18 commits
  2. 28 Aug, 2018 6 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.153 · 577189c3
      Greg Kroah-Hartman authored
      577189c3
    • Vivek Goyal's avatar
      ovl: warn instead of error if d_type is not supported · 7eaa995c
      Vivek Goyal authored
      commit e7c0b599 upstream.
      
      overlay needs underlying fs to support d_type. Recently I put in a
      patch in to detect this condition and started failing mount if
      underlying fs did not support d_type.
      
      But this breaks existing configurations over kernel upgrade. Those who
      are running docker (partially broken configuration) with xfs not
      supporting d_type, are surprised that after kernel upgrade docker does
      not run anymore.
      
      https://github.com/docker/docker/issues/22937#issuecomment-229881315
      
      So instead of erroring out, detect broken configuration and warn
      about it. This should allow existing docker setups to continue
      working after kernel upgrade.
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 45aebeaf ("ovl: Ensure upper filesystem supports d_type")
      Cc: <stable@vger.kernel.org> 4.6
      Signed-off-by: default avatarSZ Lin (林上智) <sz.lin@moxa.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7eaa995c
    • Vivek Goyal's avatar
      ovl: Do d_type check only if work dir creation was successful · 0f9a6d88
      Vivek Goyal authored
      commit 21765194 upstream.
      
      d_type check requires successful creation of workdir as iterates
      through work dir and expects work dir to be present in it. If that's
      not the case, this check will always return d_type not supported even
      if underlying filesystem might be supporting it.
      
      So don't do this check if work dir creation failed in previous step.
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarSZ Lin (林上智) <sz.lin@moxa.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f9a6d88
    • Vivek Goyal's avatar
      ovl: Ensure upper filesystem supports d_type · d5e67894
      Vivek Goyal authored
      commit 45aebeaf upstream.
      
      In some instances xfs has been created with ftype=0 and there if a file
      on lower fs is removed, overlay leaves a whiteout in upper fs but that
      whiteout does not get filtered out and is visible to overlayfs users.
      
      And reason it does not get filtered out because upper filesystem does
      not report file type of whiteout as DT_CHR during iterate_dir().
      
      So it seems to be a requirement that upper filesystem support d_type for
      overlayfs to work properly. Do this check during mount and fail if d_type
      is not supported.
      Suggested-by: default avatarDave Chinner <dchinner@redhat.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: default avatarSZ Lin (林上智) <sz.lin@moxa.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5e67894
    • Eric Biggers's avatar
      x86/mm: Fix use-after-free of ldt_struct · f9866720
      Eric Biggers authored
      commit ccd5b323 upstream.
      
      The following commit:
      
        39a0526f ("x86/mm: Factor out LDT init from context init")
      
      renamed init_new_context() to init_new_context_ldt() and added a new
      init_new_context() which calls init_new_context_ldt().  However, the
      error code of init_new_context_ldt() was ignored.  Consequently, if a
      memory allocation in alloc_ldt_struct() failed during a fork(), the
      ->context.ldt of the new task remained the same as that of the old task
      (due to the memcpy() in dup_mm()).  ldt_struct's are not intended to be
      shared, so a use-after-free occurred after one task exited.
      
      Fix the bug by making init_new_context() pass through the error code of
      init_new_context_ldt().
      
      This bug was found by syzkaller, which encountered the following splat:
      
          BUG: KASAN: use-after-free in free_ldt_struct.part.2+0x10a/0x150 arch/x86/kernel/ldt.c:116
          Read of size 4 at addr ffff88006d2cb7c8 by task kworker/u9:0/3710
      
          CPU: 1 PID: 3710 Comm: kworker/u9:0 Not tainted 4.13.0-rc4-next-20170811 #2
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
          Call Trace:
           __dump_stack lib/dump_stack.c:16 [inline]
           dump_stack+0x194/0x257 lib/dump_stack.c:52
           print_address_description+0x73/0x250 mm/kasan/report.c:252
           kasan_report_error mm/kasan/report.c:351 [inline]
           kasan_report+0x24e/0x340 mm/kasan/report.c:409
           __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
           free_ldt_struct.part.2+0x10a/0x150 arch/x86/kernel/ldt.c:116
           free_ldt_struct arch/x86/kernel/ldt.c:173 [inline]
           destroy_context_ldt+0x60/0x80 arch/x86/kernel/ldt.c:171
           destroy_context arch/x86/include/asm/mmu_context.h:157 [inline]
           __mmdrop+0xe9/0x530 kernel/fork.c:889
           mmdrop include/linux/sched/mm.h:42 [inline]
           exec_mmap fs/exec.c:1061 [inline]
           flush_old_exec+0x173c/0x1ff0 fs/exec.c:1291
           load_elf_binary+0x81f/0x4ba0 fs/binfmt_elf.c:855
           search_binary_handler+0x142/0x6b0 fs/exec.c:1652
           exec_binprm fs/exec.c:1694 [inline]
           do_execveat_common.isra.33+0x1746/0x22e0 fs/exec.c:1816
           do_execve+0x31/0x40 fs/exec.c:1860
           call_usermodehelper_exec_async+0x457/0x8f0 kernel/umh.c:100
           ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
      
          Allocated by task 3700:
           save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
           save_stack+0x43/0xd0 mm/kasan/kasan.c:447
           set_track mm/kasan/kasan.c:459 [inline]
           kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
           kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3627
           kmalloc include/linux/slab.h:493 [inline]
           alloc_ldt_struct+0x52/0x140 arch/x86/kernel/ldt.c:67
           write_ldt+0x7b7/0xab0 arch/x86/kernel/ldt.c:277
           sys_modify_ldt+0x1ef/0x240 arch/x86/kernel/ldt.c:307
           entry_SYSCALL_64_fastpath+0x1f/0xbe
      
          Freed by task 3700:
           save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
           save_stack+0x43/0xd0 mm/kasan/kasan.c:447
           set_track mm/kasan/kasan.c:459 [inline]
           kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
           __cache_free mm/slab.c:3503 [inline]
           kfree+0xca/0x250 mm/slab.c:3820
           free_ldt_struct.part.2+0xdd/0x150 arch/x86/kernel/ldt.c:121
           free_ldt_struct arch/x86/kernel/ldt.c:173 [inline]
           destroy_context_ldt+0x60/0x80 arch/x86/kernel/ldt.c:171
           destroy_context arch/x86/include/asm/mmu_context.h:157 [inline]
           __mmdrop+0xe9/0x530 kernel/fork.c:889
           mmdrop include/linux/sched/mm.h:42 [inline]
           __mmput kernel/fork.c:916 [inline]
           mmput+0x541/0x6e0 kernel/fork.c:927
           copy_process.part.36+0x22e1/0x4af0 kernel/fork.c:1931
           copy_process kernel/fork.c:1546 [inline]
           _do_fork+0x1ef/0xfb0 kernel/fork.c:2025
           SYSC_clone kernel/fork.c:2135 [inline]
           SyS_clone+0x37/0x50 kernel/fork.c:2129
           do_syscall_64+0x26c/0x8c0 arch/x86/entry/common.c:287
           return_from_SYSCALL_64+0x0/0x7a
      
      Here is a C reproducer:
      
          #include <asm/ldt.h>
          #include <pthread.h>
          #include <signal.h>
          #include <stdlib.h>
          #include <sys/syscall.h>
          #include <sys/wait.h>
          #include <unistd.h>
      
          static void *fork_thread(void *_arg)
          {
              fork();
          }
      
          int main(void)
          {
              struct user_desc desc = { .entry_number = 8191 };
      
              syscall(__NR_modify_ldt, 1, &desc, sizeof(desc));
      
              for (;;) {
                  if (fork() == 0) {
                      pthread_t t;
      
                      srand(getpid());
                      pthread_create(&t, NULL, fork_thread, NULL);
                      usleep(rand() % 10000);
                      syscall(__NR_exit_group, 0);
                  }
                  wait(NULL);
              }
          }
      
      Note: the reproducer takes advantage of the fact that alloc_ldt_struct()
      may use vmalloc() to allocate a large ->entries array, and after
      commit:
      
        5d17a73a ("vmalloc: back off when the current task is killed")
      
      it is possible for userspace to fail a task's vmalloc() by
      sending a fatal signal, e.g. via exit_group().  It would be more
      difficult to reproduce this bug on kernels without that commit.
      
      This bug only affected kernels with CONFIG_MODIFY_LDT_SYSCALL=y.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: <stable@vger.kernel.org> [v4.6+]
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Fixes: 39a0526f ("x86/mm: Factor out LDT init from context init")
      Link: http://lkml.kernel.org/r/20170824175029.76040-1-ebiggers3@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9866720
    • Andi Kleen's avatar
      x86/mm/pat: Fix L1TF stable backport for CPA · adaba23c
      Andi Kleen authored
      Patch for stable only to fix boot resets caused by the L1TF patches.
      
      Stable trees reverted the following patch
      
      Revert "x86/mm/pat: Ensure cpa->pfn only contains page frame numbers"
      
          This reverts commit 87e2bd89 which is
          commit edc3b912 upstream.
      
      but the L1TF patch backported here
      
         x86/mm/pat: Make set_memory_np() L1TF safe
      
          commit 958f79b9 upstream
      
          set_memory_np() is used to mark kernel mappings not present, but it has
          it's own open coded mechanism which does not have the L1TF protection of
          inverting the address bits.
      
      assumed that cpa->pfn contains a PFN. With the above patch reverted
      it does not, which causes the PMD to be set to an incorrect address
      shifted by 12 bits, which can cause early boot reset on some
      systems, like an Apollo Lake embedded system.
      
      Convert the address to a PFN before passing it to pmd_pfn()
      
      Thanks to Bernhard for bisecting and testing.
      
      Cc: stable@vger.kernel.org # 4.4 and 4.9
      Reported-by: default avatarBernhard Kaindl <bernhard.kaindl@thalesgroup.com>
      Tested-by: default avatarBernhard Kaindl <bernhard.kaindl@thalesgroup.com>
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      adaba23c
  3. 24 Aug, 2018 16 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.152 · 0c731696
      Greg Kroah-Hartman authored
      0c731696
    • Jann Horn's avatar
      reiserfs: fix broken xattr handling (heap corruption, bad retval) · 71225404
      Jann Horn authored
      commit a13f085d upstream.
      
      This fixes the following issues:
      
      - When a buffer size is supplied to reiserfs_listxattr() such that each
        individual name fits, but the concatenation of all names doesn't fit,
        reiserfs_listxattr() overflows the supplied buffer.  This leads to a
        kernel heap overflow (verified using KASAN) followed by an out-of-bounds
        usercopy and is therefore a security bug.
      
      - When a buffer size is supplied to reiserfs_listxattr() such that a
        name doesn't fit, -ERANGE should be returned.  But reiserfs instead just
        truncates the list of names; I have verified that if the only xattr on a
        file has a longer name than the supplied buffer length, listxattr()
        incorrectly returns zero.
      
      With my patch applied, -ERANGE is returned in both cases and the memory
      corruption doesn't happen anymore.
      
      Credit for making me clean this code up a bit goes to Al Viro, who pointed
      out that the ->actor calling convention is suboptimal and should be
      changed.
      
      Link: http://lkml.kernel.org/r/20180802151539.5373-1-jannh@google.com
      Fixes: 48b32a35 ("reiserfs: use generic xattr handlers")
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Acked-by: default avatarJeff Mahoney <jeffm@suse.com>
      Cc: Eric Biggers <ebiggers@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71225404
    • Esben Haabendal's avatar
      i2c: imx: Fix race condition in dma read · 6e57e6c6
      Esben Haabendal authored
      commit bed4ff1e upstream.
      
      This fixes a race condition, where the DMAEN bit ends up being set after
      I2C slave has transmitted a byte following the dummy read.  When that
      happens, an interrupt is generated instead, and no DMA request is generated
      to kickstart the DMA read, and a timeout happens after DMA_TIMEOUT (1 sec).
      
      Fixed by setting the DMAEN bit before the dummy read.
      Signed-off-by: default avatarEsben Haabendal <eha@deif.com>
      Acked-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e57e6c6
    • Lukas Wunner's avatar
      PCI: pciehp: Fix use-after-free on unplug · 131412f4
      Lukas Wunner authored
      commit 281e878e upstream.
      
      When pciehp is unbound (e.g. on unplug of a Thunderbolt device), the
      hotplug_slot struct is deregistered and thus freed before freeing the
      IRQ.  The IRQ handler and the work items it schedules print the slot
      name referenced from the freed structure in various informational and
      debug log messages, each time resulting in a quadruple dereference of
      freed pointers (hotplug_slot -> pci_slot -> kobject -> name).
      
      At best the slot name is logged as "(null)", at worst kernel memory is
      exposed in logs or the driver crashes:
      
        pciehp 0000:10:00.0:pcie204: Slot((null)): Card not present
      
      An attacker may provoke the bug by unplugging multiple devices on a
      Thunderbolt daisy chain at once.  Unplugging can also be simulated by
      powering down slots via sysfs.  The bug is particularly easy to trigger
      in poll mode.
      
      It has been present since the driver's introduction in 2004:
      https://git.kernel.org/tglx/history/c/c16b4b14d980
      
      Fix by rearranging teardown such that the IRQ is freed first.  Run the
      work items queued by the IRQ handler to completion before freeing the
      hotplug_slot struct by draining the work queue from the ->release_slot
      callback which is invoked by pci_hp_deregister().
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # v2.6.4
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      131412f4
    • Myron Stowe's avatar
      PCI: Skip MPS logic for Virtual Functions (VFs) · cc7614a5
      Myron Stowe authored
      commit 3dbe97ef upstream.
      
      PCIe r4.0, sec 9.3.5.4, "Device Control Register", shows both
      Max_Payload_Size (MPS) and Max_Read_request_Size (MRRS) to be 'RsvdP' for
      VFs.  Just prior to the table it states:
      
        "PF and VF functionality is defined in Section 7.5.3.4 except where
         noted in Table 9-16.  For VF fields marked 'RsvdP', the PF setting
         applies to the VF."
      
      All of which implies that with respect to Max_Payload_Size Supported
      (MPSS), MPS, and MRRS values, we should not be paying any attention to the
      VF's fields, but rather only to the PF's.  Only looking at the PF's fields
      also logically makes sense as it's the sole physical interface to the PCIe
      bus.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527
      Fixes: 27d868b5 ("PCI: Set MPS to match upstream bridge")
      Signed-off-by: default avatarMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # 4.3+
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Sinan Kaya <okaya@kernel.org>
      Cc: Dongdong Liu <liudongdong3@huawei.com>
      Cc: Jon Mason <jdmason@kudzu.us>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc7614a5
    • Lukas Wunner's avatar
      PCI: hotplug: Don't leak pci_slot on registration failure · 8837163e
      Lukas Wunner authored
      commit 4ce64358 upstream.
      
      If addition of sysfs files fails on registration of a hotplug slot, the
      struct pci_slot as well as the entry in the slot_list is leaked.  The
      issue has been present since the hotplug core was introduced in 2002:
      https://git.kernel.org/tglx/history/c/a8a2069f432c
      
      Perhaps the idea was that even though sysfs addition fails, the slot
      should still be usable.  But that's not how drivers use the interface,
      they abort probe if a non-zero value is returned.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # v2.4.15+
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8837163e
    • John David Anglin's avatar
      parisc: Remove unnecessary barriers from spinlock.h · 400db6fe
      John David Anglin authored
      commit 3b885ac1 upstream.
      
      Now that mb() is an instruction barrier, it will slow performance if we issue
      unnecessary barriers.
      
      The spinlock defines have a number of unnecessary barriers.  The __ldcw()
      define is both a hardware and compiler barrier.  The mb() barriers in the
      routines using __ldcw() serve no purpose.
      
      The only barrier needed is the one in arch_spin_unlock().  We need to ensure
      all accesses are complete prior to releasing the lock.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # 4.0+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      400db6fe
    • Elad Raz's avatar
      bridge: Propagate vlan add failure to user · 6d124ea6
      Elad Raz authored
      commit 08474cc1 upstream.
      
      Disallow adding interfaces to a bridge when vlan filtering operation
      failed. Send the failure code to the user.
      Signed-off-by: default avatarElad Raz <eladr@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSZ Lin (林上智) <sz.lin@moxa.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d124ea6
    • Willem de Bruijn's avatar
      packet: refine ring v3 block size test to hold one frame · 62c4e369
      Willem de Bruijn authored
      commit 4576cd46 upstream.
      
      TPACKET_V3 stores variable length frames in fixed length blocks.
      Blocks must be able to store a block header, optional private space
      and at least one minimum sized frame.
      
      Frames, even for a zero snaplen packet, store metadata headers and
      optional reserved space.
      
      In the block size bounds check, ensure that the frame of the
      chosen configuration fits. This includes sockaddr_ll and optional
      tp_reserve.
      
      Syzbot was able to construct a ring with insuffient room for the
      sockaddr_ll in the header of a zero-length frame, triggering an
      out-of-bounds write in dev_parse_header.
      
      Convert the comparison to less than, as zero is a valid snap len.
      This matches the test for minimum tp_frame_size immediately below.
      
      Fixes: f6fb8f10 ("af-packet: TPACKET_V3 flexible buffer implementation.")
      Fixes: eb73190f ("net/packet: refine check for priv area size")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      62c4e369
    • Florian Westphal's avatar
      netfilter: conntrack: dccp: treat SYNC/SYNCACK as invalid if no prior state · 76cb5cc6
      Florian Westphal authored
      commit 6613b617 upstream.
      
      When first DCCP packet is SYNC or SYNCACK, we insert a new conntrack
      that has an un-initialized timeout value, i.e. such entry could be
      reaped at any time.
      
      Mark them as INVALID and only ignore SYNC/SYNCACK when connection had
      an old state.
      
      Reported-by: syzbot+6f18401420df260e37ed@syzkaller.appspotmail.com
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76cb5cc6
    • Eric Dumazet's avatar
      xfrm_user: prevent leaking 2 bytes of kernel memory · 3e6170d0
      Eric Dumazet authored
      commit 45c180bc upstream.
      
      struct xfrm_userpolicy_type has two holes, so we should not
      use C99 style initializer.
      
      KMSAN report:
      
      BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:140 [inline]
      BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x1b14/0x2800 lib/iov_iter.c:571
      CPU: 1 PID: 4520 Comm: syz-executor841 Not tainted 4.17.0+ #5
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x185/0x1d0 lib/dump_stack.c:113
       kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1117
       kmsan_internal_check_memory+0x138/0x1f0 mm/kmsan/kmsan.c:1211
       kmsan_copy_to_user+0x7a/0x160 mm/kmsan/kmsan.c:1253
       copyout lib/iov_iter.c:140 [inline]
       _copy_to_iter+0x1b14/0x2800 lib/iov_iter.c:571
       copy_to_iter include/linux/uio.h:106 [inline]
       skb_copy_datagram_iter+0x422/0xfa0 net/core/datagram.c:431
       skb_copy_datagram_msg include/linux/skbuff.h:3268 [inline]
       netlink_recvmsg+0x6f1/0x1900 net/netlink/af_netlink.c:1959
       sock_recvmsg_nosec net/socket.c:802 [inline]
       sock_recvmsg+0x1d6/0x230 net/socket.c:809
       ___sys_recvmsg+0x3fe/0x810 net/socket.c:2279
       __sys_recvmmsg+0x58e/0xe30 net/socket.c:2391
       do_sys_recvmmsg+0x2a6/0x3e0 net/socket.c:2472
       __do_sys_recvmmsg net/socket.c:2485 [inline]
       __se_sys_recvmmsg net/socket.c:2481 [inline]
       __x64_sys_recvmmsg+0x15d/0x1c0 net/socket.c:2481
       do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x446ce9
      RSP: 002b:00007fc307918db8 EFLAGS: 00000293 ORIG_RAX: 000000000000012b
      RAX: ffffffffffffffda RBX: 00000000006dbc24 RCX: 0000000000446ce9
      RDX: 000000000000000a RSI: 0000000020005040 RDI: 0000000000000003
      RBP: 00000000006dbc20 R08: 0000000020004e40 R09: 0000000000000000
      R10: 0000000040000000 R11: 0000000000000293 R12: 0000000000000000
      R13: 00007ffc8d2df32f R14: 00007fc3079199c0 R15: 0000000000000001
      
      Uninit was stored to memory at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
       kmsan_save_stack mm/kmsan/kmsan.c:294 [inline]
       kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:685
       kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:527
       __msan_memcpy+0x109/0x160 mm/kmsan/kmsan_instr.c:413
       __nla_put lib/nlattr.c:569 [inline]
       nla_put+0x276/0x340 lib/nlattr.c:627
       copy_to_user_policy_type net/xfrm/xfrm_user.c:1678 [inline]
       dump_one_policy+0xbe1/0x1090 net/xfrm/xfrm_user.c:1708
       xfrm_policy_walk+0x45a/0xd00 net/xfrm/xfrm_policy.c:1013
       xfrm_dump_policy+0x1c0/0x2a0 net/xfrm/xfrm_user.c:1749
       netlink_dump+0x9b5/0x1550 net/netlink/af_netlink.c:2226
       __netlink_dump_start+0x1131/0x1270 net/netlink/af_netlink.c:2323
       netlink_dump_start include/linux/netlink.h:214 [inline]
       xfrm_user_rcv_msg+0x8a3/0x9b0 net/xfrm/xfrm_user.c:2577
       netlink_rcv_skb+0x37e/0x600 net/netlink/af_netlink.c:2448
       xfrm_netlink_rcv+0xb2/0xf0 net/xfrm/xfrm_user.c:2598
       netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
       netlink_unicast+0x1680/0x1750 net/netlink/af_netlink.c:1336
       netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
       sock_sendmsg_nosec net/socket.c:629 [inline]
       sock_sendmsg net/socket.c:639 [inline]
       ___sys_sendmsg+0xec8/0x1320 net/socket.c:2117
       __sys_sendmsg net/socket.c:2155 [inline]
       __do_sys_sendmsg net/socket.c:2164 [inline]
       __se_sys_sendmsg net/socket.c:2162 [inline]
       __x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
       do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      Local variable description: ----upt.i@dump_one_policy
      Variable was created at:
       dump_one_policy+0x78/0x1090 net/xfrm/xfrm_user.c:1689
       xfrm_policy_walk+0x45a/0xd00 net/xfrm/xfrm_policy.c:1013
      
      Byte 130 of 137 is uninitialized
      Memory access starts at ffff88019550407f
      
      Fixes: c0144bea ("[XFRM] netlink: Use nla_put()/NLA_PUT() variantes")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e6170d0
    • John David Anglin's avatar
      parisc: Remove ordered stores from syscall.S · 49b3acf7
      John David Anglin authored
      commit 7797167f upstream.
      
      Now that we use a sync prior to releasing the locks in syscall.S, we don't need
      the PA 2.0 ordered stores used to release some locks.  Using an ordered store,
      potentially slows the release and subsequent code.
      
      There are a number of other ordered stores and loads that serve no purpose.  I
      have converted these to normal stores.
      Signed-off-by: default avatarJohn David Anglin <dave.anglin@bell.net>
      Cc: stable@vger.kernel.org # 4.0+
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49b3acf7
    • Jeremy Cline's avatar
      ext4: fix spectre gadget in ext4_mb_regular_allocator() · a89f8382
      Jeremy Cline authored
      commit 1a5d5e5d upstream.
      
      'ac->ac_g_ex.fe_len' is a user-controlled value which is used in the
      derivation of 'ac->ac_2order'. 'ac->ac_2order', in turn, is used to
      index arrays which makes it a potential spectre gadget. Fix this by
      sanitizing the value assigned to 'ac->ac2_order'.  This covers the
      following accesses found with the help of smatch:
      
      * fs/ext4/mballoc.c:1896 ext4_mb_simple_scan_group() warn: potential
        spectre issue 'grp->bb_counters' [w] (local cap)
      
      * fs/ext4/mballoc.c:445 mb_find_buddy() warn: potential spectre issue
        'EXT4_SB(e4b->bd_sb)->s_mb_offsets' [r] (local cap)
      
      * fs/ext4/mballoc.c:446 mb_find_buddy() warn: potential spectre issue
        'EXT4_SB(e4b->bd_sb)->s_mb_maxs' [r] (local cap)
      Suggested-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJeremy Cline <jcline@redhat.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a89f8382
    • Paolo Bonzini's avatar
      KVM: irqfd: fix race between EPOLLHUP and irq_bypass_register_consumer · 1186a6ea
      Paolo Bonzini authored
      commit 9432a317 upstream.
      
      A comment warning against this bug is there, but the code is not doing what
      the comment says.  Therefore it is possible that an EPOLLHUP races against
      irq_bypass_register_consumer.  The EPOLLHUP handler schedules irqfd_shutdown,
      and if that runs soon enough, you get a use-after-free.
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarSudip Mukherjee <sudipm.mukherjee@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1186a6ea
    • Daniel Rosenberg's avatar
      staging: android: ion: check for kref overflow · b84ec04b
      Daniel Rosenberg authored
      This patch is against 4.4. It does not apply to master due to a large
      rework of ion in 4.12 which removed the affected functions altogther.
      4c23cbff ("staging: android: ion: Remove import interface")
      
      Userspace can cause the kref to handles to increment
      arbitrarily high. Ensure it does not overflow.
      Signed-off-by: default avatarDaniel Rosenberg <drosen@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b84ec04b
    • Randy Dunlap's avatar
      tcp: identify cryptic messages as TCP seq # bugs · 81970da6
      Randy Dunlap authored
      [ Upstream commit e56b8ce3 ]
      
      Attempt to make cryptic TCP seq number error messages clearer by
      (1) identifying the source of the message as "TCP", (2) identifying the
      errors as "seq # bug", and (3) grouping the field identifiers and values
      by separating them with commas.
      
      E.g., the following message is changed from:
      
      recvmsg bug 2: copied 73BCB6CD seq 70F17CBE rcvnxt 73BCB9AA fl 0
      WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:1881 tcp_recvmsg+0x649/0xb90
      
      to:
      
      TCP recvmsg seq # bug 2: copied 73BCB6CD, seq 70F17CBE, rcvnxt 73BCB9AA, fl 0
      WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:2011 tcp_recvmsg+0x694/0xba0
      Suggested-by: default avatar積丹尼 Dan Jacobson <jidanni@jidanni.org>
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81970da6