1. 10 Mar, 2019 40 commits
    • Daniel Borkmann's avatar
      bpf: fix sanitation rewrite in case of non-pointers · ca490a98
      Daniel Borkmann authored
      commit 3612af78 upstream.
      
      Marek reported that he saw an issue with the below snippet in that
      timing measurements where off when loaded as unpriv while results
      were reasonable when loaded as privileged:
      
          [...]
          uint64_t a = bpf_ktime_get_ns();
          uint64_t b = bpf_ktime_get_ns();
          uint64_t delta = b - a;
          if ((int64_t)delta > 0) {
          [...]
      
      Turns out there is a bug where a corner case is missing in the fix
      d3bd7413 ("bpf: fix sanitation of alu op with pointer / scalar
      type from different paths"), namely fixup_bpf_calls() only checks
      whether aux has a non-zero alu_state, but it also needs to test for
      the case of BPF_ALU_NON_POINTER since in both occasions we need to
      skip the masking rewrite (as there is nothing to mask).
      
      Fixes: d3bd7413 ("bpf: fix sanitation of alu op with pointer / scalar type from different paths")
      Reported-by: default avatarMarek Majkowski <marek@cloudflare.com>
      Reported-by: default avatarArthur Fabre <afabre@cloudflare.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/netdev/CAJPywTJqP34cK20iLM5YmUMz9KXQOdu1-+BZrGMAGgLuBWz7fg@mail.gmail.com/T/Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca490a98
    • Martin Wilck's avatar
      scsi: core: reset host byte in DID_NEXUS_FAILURE case · ebfb07e8
      Martin Wilck authored
      commit 4a067cf8 upstream.
      
      Up to 4.12, __scsi_error_from_host_byte() would reset the host byte to
      DID_OK for various cases including DID_NEXUS_FAILURE.  Commit
      2a842aca ("block: introduce new block status code type") replaced this
      function with scsi_result_to_blk_status() and removed the host-byte
      resetting code for the DID_NEXUS_FAILURE case.  As the line
      set_host_byte(cmd, DID_OK) was preserved for the other cases, I suppose
      this was an editing mistake.
      
      The fact that the host byte remains set after 4.13 is causing problems with
      the sg_persist tool, which now returns success rather then exit status 24
      when a RESERVATION CONFLICT error is encountered.
      
      Fixes: 2a842aca "block: introduce new block status code type"
      Signed-off-by: default avatarMartin Wilck <mwilck@suse.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebfb07e8
    • YueHaibing's avatar
      exec: Fix mem leak in kernel_read_file · b60d90b2
      YueHaibing authored
      commit f612acfa upstream.
      
      syzkaller report this:
      BUG: memory leak
      unreferenced object 0xffffc9000488d000 (size 9195520):
        comm "syz-executor.0", pid 2752, jiffies 4294787496 (age 18.757s)
        hex dump (first 32 bytes):
          ff ff ff ff ff ff ff ff a8 00 00 00 01 00 00 00  ................
          02 00 00 00 00 00 00 00 80 a1 7a c1 ff ff ff ff  ..........z.....
        backtrace:
          [<000000000863775c>] __vmalloc_node mm/vmalloc.c:1795 [inline]
          [<000000000863775c>] __vmalloc_node_flags mm/vmalloc.c:1809 [inline]
          [<000000000863775c>] vmalloc+0x8c/0xb0 mm/vmalloc.c:1831
          [<000000003f668111>] kernel_read_file+0x58f/0x7d0 fs/exec.c:924
          [<000000002385813f>] kernel_read_file_from_fd+0x49/0x80 fs/exec.c:993
          [<0000000011953ff1>] __do_sys_finit_module+0x13b/0x2a0 kernel/module.c:3895
          [<000000006f58491f>] do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
          [<00000000ee78baf4>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
          [<00000000241f889b>] 0xffffffffffffffff
      
      It should goto 'out_free' lable to free allocated buf while kernel_read
      fails.
      
      Fixes: 39d637af ("vfs: forbid write access when reading a file into memory")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Thibaut Sautereau <thibaut@sautereau.fr>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b60d90b2
    • Matthias Kaehlcke's avatar
      Bluetooth: Fix locking in bt_accept_enqueue() for BH context · 8d368fc5
      Matthias Kaehlcke authored
      commit c4f5627f upstream.
      
      With commit e1633762 ("Bluetooth: Handle bt_accept_enqueue() socket
      atomically") lock_sock[_nested]() is used to acquire the socket lock
      before manipulating the socket. lock_sock[_nested]() may block, which
      is problematic since bt_accept_enqueue() can be called in bottom half
      context (e.g. from rfcomm_connect_ind()):
      
      [<ffffff80080d81ec>] __might_sleep+0x4c/0x80
      [<ffffff800876c7b0>] lock_sock_nested+0x24/0x58
      [<ffffff8000d7c27c>] bt_accept_enqueue+0x48/0xd4 [bluetooth]
      [<ffffff8000e67d8c>] rfcomm_connect_ind+0x190/0x218 [rfcomm]
      
      Add a parameter to bt_accept_enqueue() to indicate whether the
      function is called from BH context, and acquire the socket lock
      with bh_lock_sock_nested() if that's the case.
      
      Also adapt all callers of bt_accept_enqueue() to pass the new
      parameter:
      
      - l2cap_sock_new_connection_cb()
        - uses lock_sock() to lock the parent socket => process context
      
      - rfcomm_connect_ind()
        - acquires the parent socket lock with bh_lock_sock() => BH
          context
      
      - __sco_chan_add()
        - called from sco_chan_add(), which is called from sco_connect().
          parent is NULL, hence bt_accept_enqueue() isn't called in this
          code path and we can ignore it
        - also called from sco_conn_ready(). uses bh_lock_sock() to acquire
          the parent lock => BH context
      
      Fixes: e1633762 ("Bluetooth: Handle bt_accept_enqueue() socket atomically")
      Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d368fc5
    • Kai-Heng Feng's avatar
      Bluetooth: btrtl: Restore old logic to assume firmware is already loaded · 43593a30
      Kai-Heng Feng authored
      commit 00df214b upstream.
      
      Realtek bluetooth may not work after reboot:
      [   12.446130] Bluetooth: hci0: RTL: rtl: unknown IC info, lmp subver a99e, hci rev 826c, hci ver 0008
      
      This is a regression introduced by commit 26503ad2 ("Bluetooth:
      btrtl: split the device initialization into smaller parts"). The new
      logic errors out early when no matching IC info can be found, in this
      case it means the firmware is already loaded.
      
      So let's assume the firmware is already loaded when we can't find
      matching IC info, like the old logic did.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201921
      Fixes: 26503ad2 ("Bluetooth: btrtl: split the device initialization into smaller parts")
      Cc: stable@vger.kernel.org # 4.19+
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43593a30
    • Luis Chamberlain's avatar
      selftests: firmware: fix verify_reqs() return value · cd61d473
      Luis Chamberlain authored
      commit 344c0152 upstream.
      
      commit a6a9be92 ("selftests: firmware: return Kselftest Skip code
      for skipped tests") by Shuah modified failures to return the special
      error code of $ksft_skip (4). We have a corner case issue where we
      *do* want to verify_reqs().
      
      Cc: <stable@vger.kernel.org> # >= 4.18
      Fixes: a6a9be92 ("selftests: firmware: return Kselftest Skip code for for skipped tests")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd61d473
    • Karoly Pados's avatar
      USB: serial: cp210x: fix GPIO in autosuspend · 9765ec7f
      Karoly Pados authored
      commit 7b0b644b upstream.
      
      Current GPIO code in cp210x fails to take USB autosuspend into account,
      making it practically impossible to use GPIOs with autosuspend enabled
      without user configuration. Fix this like for ftdi_sio in a previous patch.
      Tested on a CP2102N.
      Signed-off-by: default avatarKaroly Pados <pados@pados.hu>
      Fixes: cf5276ce ("USB: serial: cp210x: Adding GPIO support for CP2105")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9765ec7f
    • Johan Hovold's avatar
      gnss: sirf: fix premature wakeup interrupt enable · 09675c2f
      Johan Hovold authored
      commit 82f844c2 upstream.
      
      Make sure the receiver is powered (and booted) before enabling the
      wakeup interrupt to avoid spurious interrupts due to a floating input.
      
      Similarly, disable the interrupt before powering off on probe errors and
      on unbind.
      
      Fixes: d2efbbd1 ("gnss: add driver for sirfstar-based receivers")
      Cc: stable <stable@vger.kernel.org>	# 4.19
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09675c2f
    • Max Filippov's avatar
      xtensa: fix get_wchan · c426de69
      Max Filippov authored
      commit d90b88fd upstream.
      
      Stack unwinding is implemented incorrectly in xtensa get_wchan: instead
      of extracting a0 and a1 registers from the spill location under the
      stack pointer it extracts a word pointed to by the stack pointer and
      subtracts 4 or 3 from it.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c426de69
    • Bart Van Assche's avatar
      aio: Fix locking in aio_poll() · f5e66cdb
      Bart Van Assche authored
      commit d3d6a18d upstream.
      
      wake_up_locked() may but does not have to be called with interrupts
      disabled. Since the fuse filesystem calls wake_up_locked() without
      disabling interrupts aio_poll_wake() may be called with interrupts
      enabled. Since the kioctx.ctx_lock may be acquired from IRQ context,
      all code that acquires that lock from thread context must disable
      interrupts. Hence change the spin_trylock() call in aio_poll_wake()
      into a spin_trylock_irqsave() call. This patch fixes the following
      lockdep complaint:
      
      =====================================================
      WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
      5.0.0-rc4-next-20190131 #23 Not tainted
      -----------------------------------------------------
      syz-executor2/13779 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
      0000000098ac1230 (&fiq->waitq){+.+.}, at: spin_lock include/linux/spinlock.h:329 [inline]
      0000000098ac1230 (&fiq->waitq){+.+.}, at: aio_poll fs/aio.c:1772 [inline]
      0000000098ac1230 (&fiq->waitq){+.+.}, at: __io_submit_one fs/aio.c:1875 [inline]
      0000000098ac1230 (&fiq->waitq){+.+.}, at: io_submit_one+0xedf/0x1cf0 fs/aio.c:1908
      
      and this task is already holding:
      000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: spin_lock_irq include/linux/spinlock.h:354 [inline]
      000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: aio_poll fs/aio.c:1771 [inline]
      000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: __io_submit_one fs/aio.c:1875 [inline]
      000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: io_submit_one+0xeb6/0x1cf0 fs/aio.c:1908
      which would create a new lock dependency:
       (&(&ctx->ctx_lock)->rlock){..-.} -> (&fiq->waitq){+.+.}
      
      but this new dependency connects a SOFTIRQ-irq-safe lock:
       (&(&ctx->ctx_lock)->rlock){..-.}
      
      ... which became SOFTIRQ-irq-safe at:
        lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
        __raw_spin_lock_irq include/linux/spinlock_api_smp.h:128 [inline]
        _raw_spin_lock_irq+0x60/0x80 kernel/locking/spinlock.c:160
        spin_lock_irq include/linux/spinlock.h:354 [inline]
        free_ioctx_users+0x2d/0x4a0 fs/aio.c:610
        percpu_ref_put_many include/linux/percpu-refcount.h:285 [inline]
        percpu_ref_put include/linux/percpu-refcount.h:301 [inline]
        percpu_ref_call_confirm_rcu lib/percpu-refcount.c:123 [inline]
        percpu_ref_switch_to_atomic_rcu+0x3e7/0x520 lib/percpu-refcount.c:158
        __rcu_reclaim kernel/rcu/rcu.h:240 [inline]
        rcu_do_batch kernel/rcu/tree.c:2486 [inline]
        invoke_rcu_callbacks kernel/rcu/tree.c:2799 [inline]
        rcu_core+0x928/0x1390 kernel/rcu/tree.c:2780
        __do_softirq+0x266/0x95a kernel/softirq.c:292
        run_ksoftirqd kernel/softirq.c:654 [inline]
        run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646
        smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164
        kthread+0x357/0x430 kernel/kthread.c:247
        ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
      
      to a SOFTIRQ-irq-unsafe lock:
       (&fiq->waitq){+.+.}
      
      ... which became SOFTIRQ-irq-unsafe at:
      ...
        lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
        __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
        _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
        spin_lock include/linux/spinlock.h:329 [inline]
        flush_bg_queue+0x1f3/0x3c0 fs/fuse/dev.c:415
        fuse_request_queue_background+0x2d1/0x580 fs/fuse/dev.c:676
        fuse_request_send_background+0x58/0x120 fs/fuse/dev.c:687
        fuse_send_init fs/fuse/inode.c:989 [inline]
        fuse_fill_super+0x13bb/0x1730 fs/fuse/inode.c:1214
        mount_nodev+0x68/0x110 fs/super.c:1392
        fuse_mount+0x2d/0x40 fs/fuse/inode.c:1239
        legacy_get_tree+0xf2/0x200 fs/fs_context.c:590
        vfs_get_tree+0x123/0x450 fs/super.c:1481
        do_new_mount fs/namespace.c:2610 [inline]
        do_mount+0x1436/0x2c40 fs/namespace.c:2932
        ksys_mount+0xdb/0x150 fs/namespace.c:3148
        __do_sys_mount fs/namespace.c:3162 [inline]
        __se_sys_mount fs/namespace.c:3159 [inline]
        __x64_sys_mount+0xbe/0x150 fs/namespace.c:3159
        do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      other info that might help us debug this:
      
       Possible interrupt unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&fiq->waitq);
                                     local_irq_disable();
                                     lock(&(&ctx->ctx_lock)->rlock);
                                     lock(&fiq->waitq);
        <Interrupt>
          lock(&(&ctx->ctx_lock)->rlock);
      
       *** DEADLOCK ***
      
      1 lock held by syz-executor2/13779:
       #0: 000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: spin_lock_irq include/linux/spinlock.h:354 [inline]
       #0: 000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: aio_poll fs/aio.c:1771 [inline]
       #0: 000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: __io_submit_one fs/aio.c:1875 [inline]
       #0: 000000003c46111c (&(&ctx->ctx_lock)->rlock){..-.}, at: io_submit_one+0xeb6/0x1cf0 fs/aio.c:1908
      
      the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
      -> (&(&ctx->ctx_lock)->rlock){..-.} {
         IN-SOFTIRQ-W at:
                          lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
                          __raw_spin_lock_irq include/linux/spinlock_api_smp.h:128 [inline]
                          _raw_spin_lock_irq+0x60/0x80 kernel/locking/spinlock.c:160
                          spin_lock_irq include/linux/spinlock.h:354 [inline]
                          free_ioctx_users+0x2d/0x4a0 fs/aio.c:610
                          percpu_ref_put_many include/linux/percpu-refcount.h:285 [inline]
                          percpu_ref_put include/linux/percpu-refcount.h:301 [inline]
                          percpu_ref_call_confirm_rcu lib/percpu-refcount.c:123 [inline]
                          percpu_ref_switch_to_atomic_rcu+0x3e7/0x520 lib/percpu-refcount.c:158
                          __rcu_reclaim kernel/rcu/rcu.h:240 [inline]
                          rcu_do_batch kernel/rcu/tree.c:2486 [inline]
                          invoke_rcu_callbacks kernel/rcu/tree.c:2799 [inline]
                          rcu_core+0x928/0x1390 kernel/rcu/tree.c:2780
                          __do_softirq+0x266/0x95a kernel/softirq.c:292
                          run_ksoftirqd kernel/softirq.c:654 [inline]
                          run_ksoftirqd+0x8e/0x110 kernel/softirq.c:646
                          smpboot_thread_fn+0x6ab/0xa10 kernel/smpboot.c:164
                          kthread+0x357/0x430 kernel/kthread.c:247
                          ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
         INITIAL USE at:
                         lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
                         __raw_spin_lock_irq include/linux/spinlock_api_smp.h:128 [inline]
                         _raw_spin_lock_irq+0x60/0x80 kernel/locking/spinlock.c:160
                         spin_lock_irq include/linux/spinlock.h:354 [inline]
                         __do_sys_io_cancel fs/aio.c:2052 [inline]
                         __se_sys_io_cancel fs/aio.c:2035 [inline]
                         __x64_sys_io_cancel+0xd5/0x5a0 fs/aio.c:2035
                         do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
                         entry_SYSCALL_64_after_hwframe+0x49/0xbe
       }
       ... key      at: [<ffffffff8a574140>] __key.52370+0x0/0x40
       ... acquired at:
         lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
         __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
         _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
         spin_lock include/linux/spinlock.h:329 [inline]
         aio_poll fs/aio.c:1772 [inline]
         __io_submit_one fs/aio.c:1875 [inline]
         io_submit_one+0xedf/0x1cf0 fs/aio.c:1908
         __do_sys_io_submit fs/aio.c:1953 [inline]
         __se_sys_io_submit fs/aio.c:1923 [inline]
         __x64_sys_io_submit+0x1bd/0x580 fs/aio.c:1923
         do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      the dependencies between the lock to be acquired
       and SOFTIRQ-irq-unsafe lock:
      -> (&fiq->waitq){+.+.} {
         HARDIRQ-ON-W at:
                          lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
                          __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
                          _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
                          spin_lock include/linux/spinlock.h:329 [inline]
                          flush_bg_queue+0x1f3/0x3c0 fs/fuse/dev.c:415
                          fuse_request_queue_background+0x2d1/0x580 fs/fuse/dev.c:676
                          fuse_request_send_background+0x58/0x120 fs/fuse/dev.c:687
                          fuse_send_init fs/fuse/inode.c:989 [inline]
                          fuse_fill_super+0x13bb/0x1730 fs/fuse/inode.c:1214
                          mount_nodev+0x68/0x110 fs/super.c:1392
                          fuse_mount+0x2d/0x40 fs/fuse/inode.c:1239
                          legacy_get_tree+0xf2/0x200 fs/fs_context.c:590
                          vfs_get_tree+0x123/0x450 fs/super.c:1481
                          do_new_mount fs/namespace.c:2610 [inline]
                          do_mount+0x1436/0x2c40 fs/namespace.c:2932
                          ksys_mount+0xdb/0x150 fs/namespace.c:3148
                          __do_sys_mount fs/namespace.c:3162 [inline]
                          __se_sys_mount fs/namespace.c:3159 [inline]
                          __x64_sys_mount+0xbe/0x150 fs/namespace.c:3159
                          do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
                          entry_SYSCALL_64_after_hwframe+0x49/0xbe
         SOFTIRQ-ON-W at:
                          lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
                          __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
                          _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
                          spin_lock include/linux/spinlock.h:329 [inline]
                          flush_bg_queue+0x1f3/0x3c0 fs/fuse/dev.c:415
                          fuse_request_queue_background+0x2d1/0x580 fs/fuse/dev.c:676
                          fuse_request_send_background+0x58/0x120 fs/fuse/dev.c:687
                          fuse_send_init fs/fuse/inode.c:989 [inline]
                          fuse_fill_super+0x13bb/0x1730 fs/fuse/inode.c:1214
                          mount_nodev+0x68/0x110 fs/super.c:1392
                          fuse_mount+0x2d/0x40 fs/fuse/inode.c:1239
                          legacy_get_tree+0xf2/0x200 fs/fs_context.c:590
                          vfs_get_tree+0x123/0x450 fs/super.c:1481
                          do_new_mount fs/namespace.c:2610 [inline]
                          do_mount+0x1436/0x2c40 fs/namespace.c:2932
                          ksys_mount+0xdb/0x150 fs/namespace.c:3148
                          __do_sys_mount fs/namespace.c:3162 [inline]
                          __se_sys_mount fs/namespace.c:3159 [inline]
                          __x64_sys_mount+0xbe/0x150 fs/namespace.c:3159
                          do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
                          entry_SYSCALL_64_after_hwframe+0x49/0xbe
         INITIAL USE at:
                         lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
                         __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
                         _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
                         spin_lock include/linux/spinlock.h:329 [inline]
                         flush_bg_queue+0x1f3/0x3c0 fs/fuse/dev.c:415
                         fuse_request_queue_background+0x2d1/0x580 fs/fuse/dev.c:676
                         fuse_request_send_background+0x58/0x120 fs/fuse/dev.c:687
                         fuse_send_init fs/fuse/inode.c:989 [inline]
                         fuse_fill_super+0x13bb/0x1730 fs/fuse/inode.c:1214
                         mount_nodev+0x68/0x110 fs/super.c:1392
                         fuse_mount+0x2d/0x40 fs/fuse/inode.c:1239
                         legacy_get_tree+0xf2/0x200 fs/fs_context.c:590
                         vfs_get_tree+0x123/0x450 fs/super.c:1481
                         do_new_mount fs/namespace.c:2610 [inline]
                         do_mount+0x1436/0x2c40 fs/namespace.c:2932
                         ksys_mount+0xdb/0x150 fs/namespace.c:3148
                         __do_sys_mount fs/namespace.c:3162 [inline]
                         __se_sys_mount fs/namespace.c:3159 [inline]
                         __x64_sys_mount+0xbe/0x150 fs/namespace.c:3159
                         do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
                         entry_SYSCALL_64_after_hwframe+0x49/0xbe
       }
       ... key      at: [<ffffffff8a60dec0>] __key.43450+0x0/0x40
       ... acquired at:
         lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
         __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
         _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
         spin_lock include/linux/spinlock.h:329 [inline]
         aio_poll fs/aio.c:1772 [inline]
         __io_submit_one fs/aio.c:1875 [inline]
         io_submit_one+0xedf/0x1cf0 fs/aio.c:1908
         __do_sys_io_submit fs/aio.c:1953 [inline]
         __se_sys_io_submit fs/aio.c:1923 [inline]
         __x64_sys_io_submit+0x1bd/0x580 fs/aio.c:1923
         do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      stack backtrace:
      CPU: 0 PID: 13779 Comm: syz-executor2 Not tainted 5.0.0-rc4-next-20190131 #23
      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+0x172/0x1f0 lib/dump_stack.c:113
       print_bad_irq_dependency kernel/locking/lockdep.c:1573 [inline]
       check_usage.cold+0x60f/0x940 kernel/locking/lockdep.c:1605
       check_irq_usage kernel/locking/lockdep.c:1650 [inline]
       check_prev_add_irq kernel/locking/lockdep_states.h:8 [inline]
       check_prev_add kernel/locking/lockdep.c:1860 [inline]
       check_prevs_add kernel/locking/lockdep.c:1968 [inline]
       validate_chain kernel/locking/lockdep.c:2339 [inline]
       __lock_acquire+0x1f12/0x4790 kernel/locking/lockdep.c:3320
       lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3826
       __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
       _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144
       spin_lock include/linux/spinlock.h:329 [inline]
       aio_poll fs/aio.c:1772 [inline]
       __io_submit_one fs/aio.c:1875 [inline]
       io_submit_one+0xedf/0x1cf0 fs/aio.c:1908
       __do_sys_io_submit fs/aio.c:1953 [inline]
       __se_sys_io_submit fs/aio.c:1923 [inline]
       __x64_sys_io_submit+0x1bd/0x580 fs/aio.c:1923
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Avi Kivity <avi@scylladb.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: <stable@vger.kernel.org>
      Fixes: e8693bcf ("aio: allow direct aio poll comletions for keyed wakeups") # v4.19
      Signed-off-by: default avatarMiklos Szeredi <miklos@szeredi.hu>
      [ bvanassche: added a comment ]
      Reluctantly-Acked-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBart Van Assche <bvanassche@acm.org>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5e66cdb
    • Liu Xiang's avatar
      MIPS: irq: Allocate accurate order pages for irq stack · 88793c03
      Liu Xiang authored
      commit 72faa7a7 upstream.
      
      The irq_pages is the number of pages for irq stack, but not the
      order which is needed by __get_free_pages().
      We can use get_order() to calculate the accurate order.
      Signed-off-by: default avatarLiu Xiang <liu.xiang6@zte.com.cn>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: fe8bd18f ("MIPS: Introduce irq_stack")
      Cc: linux-mips@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.11+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88793c03
    • Gustavo A. R. Silva's avatar
      applicom: Fix potential Spectre v1 vulnerabilities · 5691b93f
      Gustavo A. R. Silva authored
      commit d7ac3c6e upstream.
      
      IndexCard is indirectly controlled by user-space, hence leading to
      a potential exploitation of the Spectre variant 1 vulnerability.
      
      This issue was detected with the help of Smatch:
      
      drivers/char/applicom.c:418 ac_write() warn: potential spectre issue 'apbs' [r]
      drivers/char/applicom.c:728 ac_ioctl() warn: potential spectre issue 'apbs' [r] (local cap)
      
      Fix this by sanitizing IndexCard before using it to index apbs.
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5691b93f
    • Balaji Manoharan's avatar
      usb: xhci: Fix for Enabling USB ROLE SWITCH QUIRK on INTEL_SUNRISEPOINT_LP_XHCI · 9d53e36c
      Balaji Manoharan authored
      commit 8fde481e upstream.
      
      This fix enables USB role feature on intel commercial nuc
      platform which is based on Kabylake chipset.
      Signed-off-by: default avatarBalaji Manoharan <m.balaji@intel.com>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d53e36c
    • Pavel Tikhomirov's avatar
      tracing: Fix event filters and triggers to handle negative numbers · 690e939d
      Pavel Tikhomirov authored
      commit 6a072128 upstream.
      
      Then tracing syscall exit event it is extremely useful to filter exit
      codes equal to some negative value, to react only to required errors.
      But negative numbers does not work:
      
      [root@snorch sys_exit_read]# echo "ret == -1" > filter
      bash: echo: write error: Invalid argument
      [root@snorch sys_exit_read]# cat filter
      ret == -1
              ^
      parse_error: Invalid value (did you forget quotes)?
      
      Similar thing happens when setting triggers.
      
      These is a regression in v4.17 introduced by the commit mentioned below,
      testing without these commit shows no problem with negative numbers.
      
      Link: http://lkml.kernel.org/r/20180823102534.7642-1-ptikhomirov@virtuozzo.com
      
      Cc: stable@vger.kernel.org
      Fixes: 80765597 ("tracing: Rewrite filter logic to be simpler and faster")
      Signed-off-by: default avatarPavel Tikhomirov <ptikhomirov@virtuozzo.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      690e939d
    • Kirill A. Shutemov's avatar
      x86/boot/compressed/64: Do not read legacy ROM on EFI system · 51c53180
      Kirill A. Shutemov authored
      commit 6f913de3 upstream.
      
      EFI systems do not necessarily provide a legacy ROM. If the ROM is missing
      the memory is not mapped at all.
      
      Trying to dereference values in the legacy ROM area leads to a crash on
      Macbook Pro.
      
      Only look for values in the legacy ROM area for non-EFI system.
      
      Fixes: 3548e131 ("x86/boot/compressed/64: Find a place for 32-bit trampoline")
      Reported-by: default avatarPitam Mitra <pitamm@gmail.com>
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarBockjoo Kim <bockjoo@phys.ufl.edu>
      Cc: bp@alien8.de
      Cc: hpa@zytor.com
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190219075224.35058-1-kirill.shutemov@linux.intel.com
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202351Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      51c53180
    • Jiaxun Yang's avatar
      x86/CPU/AMD: Set the CPB bit unconditionally on F17h · eab5ea25
      Jiaxun Yang authored
      commit 02371991 upstream.
      
      Some F17h models do not have CPB set in CPUID even though the CPU
      supports it. Set the feature bit unconditionally on all F17h.
      
       [ bp: Rewrite commit message and patch. ]
      Signed-off-by: default avatarJiaxun Yang <jiaxun.yang@flygoat.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>
      Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20181120030018.5185-1-jiaxun.yang@flygoat.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eab5ea25
    • Vlad Buslov's avatar
      net: sched: act_tunnel_key: fix NULL pointer dereference during init · 38460809
      Vlad Buslov authored
      [ Upstream commit a3df633a ]
      
      Metadata pointer is only initialized for action TCA_TUNNEL_KEY_ACT_SET, but
      it is unconditionally dereferenced in tunnel_key_init() error handler.
      Verify that metadata pointer is not NULL before dereferencing it in
      tunnel_key_init error handling code.
      
      Fixes: ee28bb56 ("net/sched: fix memory leak in act_tunnel_key_init()")
      Signed-off-by: default avatarVlad Buslov <vladbu@mellanox.com>
      Reviewed-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38460809
    • Davide Caratti's avatar
      net/sched: act_skbedit: fix refcount leak when replace fails · 69e6fb18
      Davide Caratti authored
      [ Upstream commit 6191da98 ]
      
      when act_skbedit was converted to use RCU in the data plane, we added an
      error path, but we forgot to drop the action refcount in case of failure
      during a 'replace' operation:
      
       # tc actions add action skbedit ptype otherhost pass index 100
       # tc action show action skbedit
       total acts 1
      
               action order 0: skbedit  ptype otherhost pass
                index 100 ref 1 bind 0
       # tc actions replace action skbedit ptype otherhost drop index 100
       RTNETLINK answers: Cannot allocate memory
       We have an error talking to the kernel
       # tc action show action skbedit
       total acts 1
      
               action order 0: skbedit  ptype otherhost pass
                index 100 ref 2 bind 0
      
      Ensure we call tcf_idr_release(), in case 'params_new' allocation failed,
      also when the action is being replaced.
      
      Fixes: c749cdda ("net/sched: act_skbedit: don't use spinlock in the data path")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      69e6fb18
    • Davide Caratti's avatar
      net/sched: act_ipt: fix refcount leak when replace fails · f1446b16
      Davide Caratti authored
      [ Upstream commit 8f67c90e ]
      
      After commit 4e8ddd7f ("net: sched: don't release reference on action
      overwrite"), the error path of all actions was converted to drop refcount
      also when the action was being overwritten. But we forgot act_ipt_init(),
      in case allocation of 'tname' was not successful:
      
       # tc action add action xt -j LOG --log-prefix hello index 100
       tablename: mangle hook: NF_IP_POST_ROUTING
               target:  LOG level warning prefix "hello" index 100
       # tc action show action xt
       total acts 1
      
               action order 0: tablename: mangle  hook: NF_IP_POST_ROUTING
               target  LOG level warning prefix "hello"
               index 100 ref 1 bind 0
       # tc action replace action xt -j LOG --log-prefix world index 100
       tablename: mangle hook: NF_IP_POST_ROUTING
               target:  LOG level warning prefix "world" index 100
       RTNETLINK answers: Cannot allocate memory
       We have an error talking to the kernel
       # tc action show action xt
       total acts 1
      
               action order 0: tablename: mangle  hook: NF_IP_POST_ROUTING
               target  LOG level warning prefix "hello"
               index 100 ref 2 bind 0
      
      Ensure we call tcf_idr_release(), in case 'tname' allocation failed, also
      when the action is being replaced.
      
      Fixes: 4e8ddd7f ("net: sched: don't release reference on action overwrite")
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f1446b16
    • Heiner Kallweit's avatar
      net: dsa: mv88e6xxx: prevent interrupt storm caused by mv88e6390x_port_set_cmode · 4d8f5df0
      Heiner Kallweit authored
      [ Upstream commit ed8fe202 ]
      
      When debugging another issue I faced an interrupt storm in this
      driver (88E6390, port 9 in SGMII mode), consisting of alternating
      link-up / link-down interrupts. Analysis showed that the driver
      wanted to set a cmode that was set already. But so far
      mv88e6390x_port_set_cmode() doesn't check this and powers down
      SERDES, what causes the link to break, and eventually results in
      the described interrupt storm.
      
      Fix this by checking whether the cmode actually changes. We want
      that the very first call to mv88e6390x_port_set_cmode() always
      configures the registers, therefore initialize port.cmode with
      a value that is different from any supported cmode value.
      We have to take care that we only init the ports cmode once
      chip->info->num_ports is set.
      
      v2:
      - add small helper and init the number of actual ports only
      
      Fixes: 364e9d77 ("net: dsa: mv88e6xxx: Power on/off SERDES on cmode change")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d8f5df0
    • Maxime Chevallier's avatar
      net: dsa: mv88e6xxx: power serdes on/off for 10G interfaces on 6390X · 457c1190
      Maxime Chevallier authored
      [ Upstream commit d235c48b ]
      
      Upon setting the cmode on 6390 and 6390X, the associated serdes
      interfaces must be powered off/on.
      
      Both 6390X and 6390 share code to do so, but it currently uses the 6390
      specific helper mv88e6390_serdes_power() to disable and enable the
      serdes interface.
      
      This call will fail silently on 6390X when trying so set a 10G interface
      such as XAUI or RXAUI, since mv88e6390_serdes_power() internally grabs
      the lane number based on modes supported by the 6390, and returns 0 when
      getting -ENODEV as a lane number.
      
      Using mv88e6390x_serdes_power() should be safe here, since we explicitly
      rule-out all ports but the 9 and 10, and because modes supported by 6390
      ports 9 and 10 are a subset of those supported on 6390X.
      
      This was tested on 6390X using RXAUI mode.
      
      Fixes: 364e9d77 ("net: dsa: mv88e6xxx: Power on/off SERDES on cmode change")
      Signed-off-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      457c1190
    • David Ahern's avatar
      ipv4: Pass original device to ip_rcv_finish_core · cc211561
      David Ahern authored
      [ Upstream commit a1fd1ad2 ]
      
      ip_route_input_rcu expects the original ingress device (e.g., for
      proper multicast handling). The skb->dev can be changed by l3mdev_ip_rcv,
      so dev needs to be saved prior to calling it. This was the behavior prior
      to the listify changes.
      
      Fixes: 5fa12739 ("net: ipv4: listify ip_rcv_finish")
      Cc: Edward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc211561
    • David Ahern's avatar
      mpls: Return error for RTA_GATEWAY attribute · 4f3221de
      David Ahern authored
      [ Upstream commit be48220e ]
      
      MPLS does not support nexthops with an MPLS address family.
      Specifically, it does not handle RTA_GATEWAY attribute. Make it
      clear by returning an error.
      
      Fixes: 03c05665 ("mpls: Netlink commands to add, remove, and dump routes")
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f3221de
    • David Ahern's avatar
      ipv6: Return error for RTA_VIA attribute · a68d31cc
      David Ahern authored
      [ Upstream commit e3818541 ]
      
      IPv6 currently does not support nexthops outside of the AF_INET6 family.
      Specifically, it does not handle RTA_VIA attribute. If it is passed
      in a route add request, the actual route added only uses the device
      which is clearly not what the user intended:
      
        $ ip -6 ro add 2001:db8:2::/64 via inet 172.16.1.1 dev eth0
        $ ip ro ls
        ...
        2001:db8:2::/64 dev eth0 metric 1024 pref medium
      
      Catch this and fail the route add:
        $ ip -6 ro add 2001:db8:2::/64 via inet 172.16.1.1 dev eth0
        Error: IPv6 does not support RTA_VIA attribute.
      
      Fixes: 03c05665 ("mpls: Netlink commands to add, remove, and dump routes")
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a68d31cc
    • David Ahern's avatar
      ipv4: Return error for RTA_VIA attribute · 8c0aa3f6
      David Ahern authored
      [ Upstream commit b6e9e5df ]
      
      IPv4 currently does not support nexthops outside of the AF_INET family.
      Specifically, it does not handle RTA_VIA attribute. If it is passed
      in a route add request, the actual route added only uses the device
      which is clearly not what the user intended:
      
        $ ip ro add 172.16.1.0/24 via inet6 2001:db8:1::1 dev eth0
        $ ip ro ls
        ...
        172.16.1.0/24 dev eth0
      
      Catch this and fail the route add:
        $ ip ro add 172.16.1.0/24 via inet6 2001:db8:1::1 dev eth0
        Error: IPv4 does not support RTA_VIA attribute.
      
      Fixes: 03c05665 ("mpls: Netlink commands to add, remove, and dump routes")
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c0aa3f6
    • Nazarov Sergey's avatar
      net: avoid use IPCB in cipso_v4_error · 125bc1e6
      Nazarov Sergey authored
      [ Upstream commit 3da1ed7a ]
      
      Extract IP options in cipso_v4_error and use __icmp_send.
      Signed-off-by: default avatarSergey Nazarov <s-nazarov@yandex.ru>
      Acked-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      125bc1e6
    • Nazarov Sergey's avatar
      net: Add __icmp_send helper. · f2397468
      Nazarov Sergey authored
      [ Upstream commit 9ef6b42a ]
      
      Add __icmp_send function having ip_options struct parameter
      Signed-off-by: default avatarSergey Nazarov <s-nazarov@yandex.ru>
      Reviewed-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2397468
    • Timur Celik's avatar
      tun: remove unnecessary memory barrier · e6620def
      Timur Celik authored
      [ Upstream commit ecef67cb ]
      
      Replace set_current_state with __set_current_state since no memory
      barrier is needed at this point.
      Signed-off-by: default avatarTimur Celik <mail@timurcelik.de>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e6620def
    • Igor Druzhinin's avatar
      xen-netback: fix occasional leak of grant ref mappings under memory pressure · 947fc52b
      Igor Druzhinin authored
      [ Upstream commit 99e87f56 ]
      
      Zero-copy callback flag is not yet set on frag list skb at the moment
      xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
      leaking grant ref mappings since xenvif_zerocopy_callback() is never
      called for these fragments. Those eventually build up and cause Xen
      to kill Dom0 as the slots get reused for new mappings:
      
      "d0v0 Attempt to implicitly unmap a granted PTE c010000329fce005"
      
      That behavior is observed under certain workloads where sudden spikes
      of page cache writes coexist with active atomic skb allocations from
      network traffic. Additionally, rework the logic to deal with frag_list
      deallocation in a single place.
      Signed-off-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Signed-off-by: default avatarIgor Druzhinin <igor.druzhinin@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      947fc52b
    • Igor Druzhinin's avatar
      xen-netback: don't populate the hash cache on XenBus disconnect · e5e58401
      Igor Druzhinin authored
      [ Upstream commit a2288d4e ]
      
      Occasionally, during the disconnection procedure on XenBus which
      includes hash cache deinitialization there might be some packets
      still in-flight on other processors. Handling of these packets includes
      hashing and hash cache population that finally results in hash cache
      data structure corruption.
      
      In order to avoid this we prevent hashing of those packets if there
      are no queues initialized. In that case RCU protection of queues guards
      the hash cache as well.
      Signed-off-by: default avatarIgor Druzhinin <igor.druzhinin@citrix.com>
      Reviewed-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e5e58401
    • Timur Celik's avatar
      tun: fix blocking read · 488b9407
      Timur Celik authored
      [ Upstream commit 71828b22 ]
      
      This patch moves setting of the current state into the loop. Otherwise
      the task may end up in a busy wait loop if none of the break conditions
      are met.
      Signed-off-by: default avatarTimur Celik <mail@timurcelik.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      488b9407
    • Tung Nguyen's avatar
      tipc: fix race condition causing hung sendto · ab04570d
      Tung Nguyen authored
      [ Upstream commit bfd07f3d ]
      
      When sending multicast messages via blocking socket,
      if sending link is congested (tsk->cong_link_cnt is set to 1),
      the sending thread will be put into sleeping state. However,
      tipc_sk_filter_rcv() is called under socket spin lock but
      tipc_wait_for_cond() is not. So, there is no guarantee that
      the setting of tsk->cong_link_cnt to 0 in tipc_sk_proto_rcv() in
      CPU-1 will be perceived by CPU-0. If that is the case, the sending
      thread in CPU-0 after being waken up, will continue to see
      tsk->cong_link_cnt as 1 and put the sending thread into sleeping
      state again. The sending thread will sleep forever.
      
      CPU-0                                | CPU-1
      tipc_wait_for_cond()                 |
      {                                    |
       // condition_ = !tsk->cong_link_cnt |
       while ((rc_ = !(condition_))) {     |
        ...                                |
        release_sock(sk_);                 |
        wait_woken();                      |
                                           | if (!sock_owned_by_user(sk))
                                           |  tipc_sk_filter_rcv()
                                           |  {
                                           |   ...
                                           |   tipc_sk_proto_rcv()
                                           |   {
                                           |    ...
                                           |    tsk->cong_link_cnt--;
                                           |    ...
                                           |    sk->sk_write_space(sk);
                                           |    ...
                                           |   }
                                           |   ...
                                           |  }
        sched_annotate_sleep();            |
        lock_sock(sk_);                    |
        remove_wait_queue();               |
       }                                   |
      }                                    |
      
      This commit fixes it by adding memory barrier to tipc_sk_proto_rcv()
      and tipc_wait_for_cond().
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarTung Nguyen <tung.q.nguyen@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab04570d
    • Eric Biggers's avatar
      net: socket: set sock->sk to NULL after calling proto_ops::release() · 5fdb551f
      Eric Biggers authored
      [ Upstream commit ff7b11aa ]
      
      Commit 9060cb71 ("net: crypto set sk to NULL when af_alg_release.")
      fixed a use-after-free in sockfs_setattr() when an AF_ALG socket is
      closed concurrently with fchownat().  However, it ignored that many
      other proto_ops::release() methods don't set sock->sk to NULL and
      therefore allow the same use-after-free:
      
          - base_sock_release
          - bnep_sock_release
          - cmtp_sock_release
          - data_sock_release
          - dn_release
          - hci_sock_release
          - hidp_sock_release
          - iucv_sock_release
          - l2cap_sock_release
          - llcp_sock_release
          - llc_ui_release
          - rawsock_release
          - rfcomm_sock_release
          - sco_sock_release
          - svc_release
          - vcc_release
          - x25_release
      
      Rather than fixing all these and relying on every socket type to get
      this right forever, just make __sock_release() set sock->sk to NULL
      itself after calling proto_ops::release().
      
      Reproducer that produces the KASAN splat when any of these socket types
      are configured into the kernel:
      
          #include <pthread.h>
          #include <stdlib.h>
          #include <sys/socket.h>
          #include <unistd.h>
      
          pthread_t t;
          volatile int fd;
      
          void *close_thread(void *arg)
          {
              for (;;) {
                  usleep(rand() % 100);
                  close(fd);
              }
          }
      
          int main()
          {
              pthread_create(&t, NULL, close_thread, NULL);
              for (;;) {
                  fd = socket(rand() % 50, rand() % 11, 0);
                  fchownat(fd, "", 1000, 1000, 0x1000);
                  close(fd);
              }
          }
      
      Fixes: 86741ec2 ("net: core: Add a UID field to struct sock.")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5fdb551f
    • Mao Wenan's avatar
      net: sit: fix memory leak in sit_init_net() · d0bedaac
      Mao Wenan authored
      [ Upstream commit 07f12b26 ]
      
      If register_netdev() is failed to register sitn->fb_tunnel_dev,
      it will go to err_reg_dev and forget to free netdev(sitn->fb_tunnel_dev).
      
      BUG: memory leak
      unreferenced object 0xffff888378daad00 (size 512):
        comm "syz-executor.1", pid 4006, jiffies 4295121142 (age 16.115s)
        hex dump (first 32 bytes):
          00 e6 ed c0 83 88 ff ff 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
          [<00000000d6dcb63e>] kvmalloc include/linux/mm.h:577 [inline]
          [<00000000d6dcb63e>] kvzalloc include/linux/mm.h:585 [inline]
          [<00000000d6dcb63e>] netif_alloc_netdev_queues net/core/dev.c:8380 [inline]
          [<00000000d6dcb63e>] alloc_netdev_mqs+0x600/0xcc0 net/core/dev.c:8970
          [<00000000867e172f>] sit_init_net+0x295/0xa40 net/ipv6/sit.c:1848
          [<00000000871019fa>] ops_init+0xad/0x3e0 net/core/net_namespace.c:129
          [<00000000319507f6>] setup_net+0x2ba/0x690 net/core/net_namespace.c:314
          [<0000000087db4f96>] copy_net_ns+0x1dc/0x330 net/core/net_namespace.c:437
          [<0000000057efc651>] create_new_namespaces+0x382/0x730 kernel/nsproxy.c:107
          [<00000000676f83de>] copy_namespaces+0x2ed/0x3d0 kernel/nsproxy.c:165
          [<0000000030b74bac>] copy_process.part.27+0x231e/0x6db0 kernel/fork.c:1919
          [<00000000fff78746>] copy_process kernel/fork.c:1713 [inline]
          [<00000000fff78746>] _do_fork+0x1bc/0xe90 kernel/fork.c:2224
          [<000000001c2e0d1c>] do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
          [<00000000ec48bd44>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
          [<0000000039acff8a>] 0xffffffffffffffff
      Signed-off-by: default avatarMao Wenan <maowenan@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0bedaac
    • Heiner Kallweit's avatar
      net: phy: phylink: fix uninitialized variable in phylink_get_mac_state · ed7a5441
      Heiner Kallweit authored
      [ Upstream commit d25ed413 ]
      
      When debugging an issue I found implausible values in state->pause.
      Reason in that state->pause isn't initialized and later only single
      bits are changed. Also the struct itself isn't initialized in
      phylink_resolve(). So better initialize state->pause and other
      not yet initialized fields.
      
      v2:
      - use right function name in subject
      v3:
      - initialize additional fields
      
      Fixes: 9525ae83 ("phylink: add phylink infrastructure")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ed7a5441
    • Rajasingh Thavamani's avatar
      net: phy: Micrel KSZ8061: link failure after cable connect · d0681689
      Rajasingh Thavamani authored
      [ Upstream commit 232ba3a5 ]
      
      With Micrel KSZ8061 PHY, the link may occasionally not come up after
      Ethernet cable connect. The vendor's (Microchip, former Micrel) errata
      sheet 80000688A.pdf descripes the problem and possible workarounds in
      detail, see below.
      The batch implements workaround 1, which permanently fixes the issue.
      
      DESCRIPTION
      Link-up may not occur properly when the Ethernet cable is initially
      connected. This issue occurs more commonly when the cable is connected
      slowly, but it may occur any time a cable is connected. This issue occurs
      in the auto-negotiation circuit, and will not occur if auto-negotiation
      is disabled (which requires that the two link partners be set to the
      same speed and duplex).
      
      END USER IMPLICATIONS
      When this issue occurs, link is not established. Subsequent cable
      plug/unplaug cycle will not correct the issue.
      
      WORk AROUND
      There are four approaches to work around this issue:
      1. This issue can be prevented by setting bit 15 in MMD device address 1,
         register 2, prior to connecting the cable or prior to setting the
         Restart Auto-negotiation bit in register 0h. The MMD registers are
         accessed via the indirect access registers Dh and Eh, or via the Micrel
         EthUtil utility as shown here:
         . if using the EthUtil utility (usually with a Micrel KSZ8061
           Evaluation Board), type the following commands:
           > address 1
           > mmd 1
           > iw 2 b61a
         . Alternatively, write the following registers to write to the
           indirect MMD register:
           Write register Dh, data 0001h
           Write register Eh, data 0002h
           Write register Dh, data 4001h
           Write register Eh, data B61Ah
      2. The issue can be avoided by disabling auto-negotiation in the KSZ8061,
         either by the strapping option, or by clearing bit 12 in register 0h.
         Care must be taken to ensure that the KSZ8061 and the link partner
         will link with the same speed and duplex. Note that the KSZ8061
         defaults to full-duplex when auto-negotiation is off, but other
         devices may default to half-duplex in the event of failed
         auto-negotiation.
      3. The issue can be avoided by connecting the cable prior to powering-up
         or resetting the KSZ8061, and leaving it plugged in thereafter.
      4. If the above measures are not taken and the problem occurs, link can
         be recovered by setting the Restart Auto-Negotiation bit in
         register 0h, or by resetting or power cycling the device. Reset may
         be either hardware reset or software reset (register 0h, bit 15).
      
      PLAN
      This errata will not be corrected in the future revision.
      
      Fixes: 7ab59dc1 ("drivers/net/phy/micrel_phy: Add support for new PHYs")
      Signed-off-by: default avatarAlexander Onnasch <alexander.onnasch@landisgyr.com>
      Signed-off-by: default avatarRajasingh Thavamani <T.Rajasingh@landisgyr.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d0681689
    • YueHaibing's avatar
      net: nfc: Fix NULL dereference on nfc_llcp_build_tlv fails · f132b3f5
      YueHaibing authored
      [ Upstream commit 58bdd544 ]
      
      KASAN report this:
      
      BUG: KASAN: null-ptr-deref in nfc_llcp_build_gb+0x37f/0x540 [nfc]
      Read of size 3 at addr 0000000000000000 by task syz-executor.0/5401
      
      CPU: 0 PID: 5401 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xfa/0x1ce lib/dump_stack.c:113
       kasan_report+0x171/0x18d mm/kasan/report.c:321
       memcpy+0x1f/0x50 mm/kasan/common.c:130
       nfc_llcp_build_gb+0x37f/0x540 [nfc]
       nfc_llcp_register_device+0x6eb/0xb50 [nfc]
       nfc_register_device+0x50/0x1d0 [nfc]
       nfcsim_device_new+0x394/0x67d [nfcsim]
       ? 0xffffffffc1080000
       nfcsim_init+0x6b/0x1000 [nfcsim]
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f9cb79dcc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000003
      RBP: 00007f9cb79dcc70 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9cb79dd6bc
      R13: 00000000004bcefb R14: 00000000006f7030 R15: 0000000000000004
      
      nfc_llcp_build_tlv will return NULL on fails, caller should check it,
      otherwise will trigger a NULL dereference.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: eda21f16 ("NFC: Set MIU and RW values from CONNECT and CC LLCP frames")
      Fixes: d646960f ("NFC: Initial LLCP support")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f132b3f5
    • Sheng Lan's avatar
      net: netem: fix skb length BUG_ON in __skb_to_sgvec · d1dd2e15
      Sheng Lan authored
      [ Upstream commit 5845f706 ]
      
      It can be reproduced by following steps:
      1. virtio_net NIC is configured with gso/tso on
      2. configure nginx as http server with an index file bigger than 1M bytes
      3. use tc netem to produce duplicate packets and delay:
         tc qdisc add dev eth0 root netem delay 100ms 10ms 30% duplicate 90%
      4. continually curl the nginx http server to get index file on client
      5. BUG_ON is seen quickly
      
      [10258690.371129] kernel BUG at net/core/skbuff.c:4028!
      [10258690.371748] invalid opcode: 0000 [#1] SMP PTI
      [10258690.372094] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G        W         5.0.0-rc6 #2
      [10258690.372094] RSP: 0018:ffffa05797b43da0 EFLAGS: 00010202
      [10258690.372094] RBP: 00000000000005ea R08: 0000000000000000 R09: 00000000000005ea
      [10258690.372094] R10: ffffa0579334d800 R11: 00000000000002c0 R12: 0000000000000002
      [10258690.372094] R13: 0000000000000000 R14: ffffa05793122900 R15: ffffa0578f7cb028
      [10258690.372094] FS:  0000000000000000(0000) GS:ffffa05797b40000(0000) knlGS:0000000000000000
      [10258690.372094] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [10258690.372094] CR2: 00007f1a6dc00868 CR3: 000000001000e000 CR4: 00000000000006e0
      [10258690.372094] Call Trace:
      [10258690.372094]  <IRQ>
      [10258690.372094]  skb_to_sgvec+0x11/0x40
      [10258690.372094]  start_xmit+0x38c/0x520 [virtio_net]
      [10258690.372094]  dev_hard_start_xmit+0x9b/0x200
      [10258690.372094]  sch_direct_xmit+0xff/0x260
      [10258690.372094]  __qdisc_run+0x15e/0x4e0
      [10258690.372094]  net_tx_action+0x137/0x210
      [10258690.372094]  __do_softirq+0xd6/0x2a9
      [10258690.372094]  irq_exit+0xde/0xf0
      [10258690.372094]  smp_apic_timer_interrupt+0x74/0x140
      [10258690.372094]  apic_timer_interrupt+0xf/0x20
      [10258690.372094]  </IRQ>
      
      In __skb_to_sgvec(), the skb->len is not equal to the sum of the skb's
      linear data size and nonlinear data size, thus BUG_ON triggered.
      Because the skb is cloned and a part of nonlinear data is split off.
      
      Duplicate packet is cloned in netem_enqueue() and may be delayed
      some time in qdisc. When qdisc len reached the limit and returns
      NET_XMIT_DROP, the skb will be retransmit later in write queue.
      the skb will be fragmented by tso_fragment(), the limit size
      that depends on cwnd and mss decrease, the skb's nonlinear
      data will be split off. The length of the skb cloned by netem
      will not be updated. When we use virtio_net NIC and invoke skb_to_sgvec(),
      the BUG_ON trigger.
      
      To fix it, netem returns NET_XMIT_SUCCESS to upper stack
      when it clones a duplicate packet.
      
      Fixes: 35d889d1 ("sch_netem: fix skb leak in netem_enqueue()")
      Signed-off-by: default avatarSheng Lan <lansheng@huawei.com>
      Reported-by: default avatarQin Ji <jiqin.ji@huawei.com>
      Suggested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1dd2e15
    • Paul Moore's avatar
      netlabel: fix out-of-bounds memory accesses · e3713abc
      Paul Moore authored
      [ Upstream commit 5578de48 ]
      
      There are two array out-of-bounds memory accesses, one in
      cipso_v4_map_lvl_valid(), the other in netlbl_bitmap_walk().  Both
      errors are embarassingly simple, and the fixes are straightforward.
      
      As a FYI for anyone backporting this patch to kernels prior to v4.8,
      you'll want to apply the netlbl_bitmap_walk() patch to
      cipso_v4_bitmap_walk() as netlbl_bitmap_walk() doesn't exist before
      Linux v4.8.
      Reported-by: default avatarJann Horn <jannh@google.com>
      Fixes: 446fda4f ("[NetLabel]: CIPSOv4 engine")
      Fixes: 3faa8f98 ("netlabel: Move bitmap manipulation functions to the NetLabel core.")
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3713abc
    • Andrew Lunn's avatar
      net: dsa: mv88e6xxx: Fix u64 statistics · 4afc9831
      Andrew Lunn authored
      [ Upstream commit 6e46e2d8 ]
      
      The switch maintains u64 counters for the number of octets sent and
      received. These are kept as two u32's which need to be combined.  Fix
      the combing, which wrongly worked on u16's.
      
      Fixes: 80c4627b ("dsa: mv88x6xxx: Refactor getting a single statistic")
      Reported-by: default avatarChris Healy <Chris.Healy@zii.aero>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4afc9831