1. 03 Oct, 2016 16 commits
    • Matt Redfearn's avatar
      MIPS: paravirt: Fix undefined reference to smp_bootstrap · ebed93dc
      Matt Redfearn authored
      [ Upstream commit 951c39cd ]
      
      If the paravirt machine is compiles without CONFIG_SMP, the following
      linker error occurs
      
      arch/mips/kernel/head.o: In function `kernel_entry':
      (.ref.text+0x10): undefined reference to `smp_bootstrap'
      
      due to the kernel entry macro always including SMP startup code.
      Wrap this code in CONFIG_SMP to fix the error.
      Signed-off-by: default avatarMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # 3.16+
      Patchwork: https://patchwork.linux-mips.org/patch/14212/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ebed93dc
    • Ard Biesheuvel's avatar
      crypto: arm64/aes-ctr - fix NULL dereference in tail processing · 3e81f024
      Ard Biesheuvel authored
      [ Upstream commit 2db34e78 ]
      
      The AES-CTR glue code avoids calling into the blkcipher API for the
      tail portion of the walk, by comparing the remainder of walk.nbytes
      modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
      into the tail processing block if they are equal. This tail processing
      block checks whether nbytes != 0, and does nothing otherwise.
      
      However, in case of an allocation failure in the blkcipher layer, we
      may enter this code with walk.nbytes == 0, while nbytes > 0. In this
      case, we should not dereference the source and destination pointers,
      since they may be NULL. So instead of checking for nbytes != 0, check
      for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
      non-error conditions.
      
      Fixes: 49788fe2 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarxiakaixu <xiakaixu@huawei.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3e81f024
    • Ard Biesheuvel's avatar
      crypto: arm/aes-ctr - fix NULL dereference in tail processing · 3b7df386
      Ard Biesheuvel authored
      [ Upstream commit f82e90b2 ]
      
      The AES-CTR glue code avoids calling into the blkcipher API for the
      tail portion of the walk, by comparing the remainder of walk.nbytes
      modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
      into the tail processing block if they are equal. This tail processing
      block checks whether nbytes != 0, and does nothing otherwise.
      
      However, in case of an allocation failure in the blkcipher layer, we
      may enter this code with walk.nbytes == 0, while nbytes > 0. In this
      case, we should not dereference the source and destination pointers,
      since they may be NULL. So instead of checking for nbytes != 0, check
      for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
      non-error conditions.
      
      Fixes: 86464859 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarxiakaixu <xiakaixu@huawei.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      3b7df386
    • Herbert Xu's avatar
      crypto: skcipher - Fix blkcipher walk OOM crash · a55614f1
      Herbert Xu authored
      [ Upstream commit acdb04d0 ]
      
      When we need to allocate a temporary blkcipher_walk_next and it
      fails, the code is supposed to take the slow path of processing
      the data block by block.  However, due to an unrelated change
      we instead end up dereferencing the NULL pointer.
      
      This patch fixes it by moving the unrelated bsize setting out
      of the way so that we enter the slow path as inteded.
      
      Fixes: 7607bd8f ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarxiakaixu <xiakaixu@huawei.com>
      Reported-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      a55614f1
    • Daniele Palmas's avatar
      USB: serial: simple: add support for another Infineon flashloader · ce2fe081
      Daniele Palmas authored
      [ Upstream commit f190fd92 ]
      
      This patch adds support for Infineon flashloader 0x8087/0x0801.
      
      The flashloader is used in Telit LE940B modem family with Telit
      flashing application.
      Signed-off-by: default avatarDaniele Palmas <dnlplm@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ce2fe081
    • Trond Myklebust's avatar
      NFSv4.1: Fix the CREATE_SESSION slot number accounting · f40afeeb
      Trond Myklebust authored
      [ Upstream commit b519d408 ]
      
      Ensure that we conform to the algorithm described in RFC5661, section
      18.36.4 for when to bump the sequence id. In essence we do it for all
      cases except when the RPC call timed out, or in case of the server returning
      NFS4ERR_DELAY or NFS4ERR_STALE_CLIENTID.
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f40afeeb
    • Eric Biggers's avatar
      fscrypto: require write access to mount to set encryption policy · 41beb77f
      Eric Biggers authored
      [ Upstream commit ba63f23d ]
      
      Since setting an encryption policy requires writing metadata to the
      filesystem, it should be guarded by mnt_want_write/mnt_drop_write.
      Otherwise, a user could cause a write to a frozen or readonly
      filesystem.  This was handled correctly by f2fs but not by ext4.  Make
      fscrypt_process_policy() handle it rather than relying on the filesystem
      to get it right.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Cc: stable@vger.kernel.org # 4.1+; check fs/{ext4,f2fs}
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Acked-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      41beb77f
    • Al Viro's avatar
      asm-generic: make copy_from_user() zero the destination properly · 08ac15d0
      Al Viro authored
      [ Upstream commit 2545e5da ]
      
      ... in all cases, including the failing access_ok()
      
      Note that some architectures using asm-generic/uaccess.h have
      __copy_from_user() not zeroing the tail on failure halfway
      through.  This variant works either way.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      08ac15d0
    • Al Viro's avatar
      alpha: fix copy_from_user() · ca79a8db
      Al Viro authored
      [ Upstream commit 2561d309 ]
      
      it should clear the destination even when access_ok() fails.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      ca79a8db
    • Will Deacon's avatar
      arm64: spinlocks: implement smp_mb__before_spinlock() as smp_mb() · f2ec3a1c
      Will Deacon authored
      [ Upstream commit 872c63fb ]
      
      smp_mb__before_spinlock() is intended to upgrade a spin_lock() operation
      to a full barrier, such that prior stores are ordered with respect to
      loads and stores occuring inside the critical section.
      
      Unfortunately, the core code defines the barrier as smp_wmb(), which
      is insufficient to provide the required ordering guarantees when used in
      conjunction with our load-acquire-based spinlock implementation.
      
      This patch overrides the arm64 definition of smp_mb__before_spinlock()
      to map to a full smp_mb().
      
      Cc: <stable@vger.kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Reported-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      f2ec3a1c
    • Suzuki K Poulose's avatar
      kvm-arm: Unmap shadow pagetables properly · 323d5348
      Suzuki K Poulose authored
      [ Upstream commit 293f2936 ]
      
      On arm/arm64, we depend on the kvm_unmap_hva* callbacks (via
      mmu_notifiers::invalidate_*) to unmap the stage2 pagetables when
      the userspace buffer gets unmapped. However, when the Hypervisor
      process exits without explicit unmap of the guest buffers, the only
      notifier we get is kvm_arch_flush_shadow_all() (via mmu_notifier::release
      ) which does nothing on arm. Later this causes us to access pages that
      were already released [via exit_mmap() -> unmap_vmas()] when we actually
      get to unmap the stage2 pagetable [via kvm_arch_destroy_vm() ->
      kvm_free_stage2_pgd()]. This triggers crashes with CONFIG_DEBUG_PAGEALLOC,
      which unmaps any free'd pages from the linear map.
      
       [  757.644120] Unable to handle kernel paging request at virtual address
        ffff800661e00000
       [  757.652046] pgd = ffff20000b1a2000
       [  757.655471] [ffff800661e00000] *pgd=00000047fffe3003, *pud=00000047fcd8c003,
        *pmd=00000047fcc7c003, *pte=00e8004661e00712
       [  757.666492] Internal error: Oops: 96000147 [#3] PREEMPT SMP
       [  757.672041] Modules linked in:
       [  757.675100] CPU: 7 PID: 3630 Comm: qemu-system-aar Tainted: G      D
       4.8.0-rc1 #3
       [  757.683240] Hardware name: AppliedMicro X-Gene Mustang Board/X-Gene Mustang Board,
        BIOS 3.06.15 Aug 19 2016
       [  757.692938] task: ffff80069cdd3580 task.stack: ffff8006adb7c000
       [  757.698840] PC is at __flush_dcache_area+0x1c/0x40
       [  757.703613] LR is at kvm_flush_dcache_pmd+0x60/0x70
       [  757.708469] pc : [<ffff20000809dbdc>] lr : [<ffff2000080b4a70>] pstate: 20000145
       ...
       [  758.357249] [<ffff20000809dbdc>] __flush_dcache_area+0x1c/0x40
       [  758.363059] [<ffff2000080b6748>] unmap_stage2_range+0x458/0x5f0
       [  758.368954] [<ffff2000080b708c>] kvm_free_stage2_pgd+0x34/0x60
       [  758.374761] [<ffff2000080b2280>] kvm_arch_destroy_vm+0x20/0x68
       [  758.380570] [<ffff2000080aa330>] kvm_put_kvm+0x210/0x358
       [  758.385860] [<ffff2000080aa524>] kvm_vm_release+0x2c/0x40
       [  758.391239] [<ffff2000082ad234>] __fput+0x114/0x2e8
       [  758.396096] [<ffff2000082ad46c>] ____fput+0xc/0x18
       [  758.400869] [<ffff200008104658>] task_work_run+0x108/0x138
       [  758.406332] [<ffff2000080dc8ec>] do_exit+0x48c/0x10e8
       [  758.411363] [<ffff2000080dd5fc>] do_group_exit+0x6c/0x130
       [  758.416739] [<ffff2000080ed924>] get_signal+0x284/0xa18
       [  758.421943] [<ffff20000808a098>] do_signal+0x158/0x860
       [  758.427060] [<ffff20000808aad4>] do_notify_resume+0x6c/0x88
       [  758.432608] [<ffff200008083624>] work_pending+0x10/0x14
       [  758.437812] Code: 9ac32042 8b010001 d1000443 8a230000 (d50b7e20)
      
      This patch fixes the issue by moving the kvm_free_stage2_pgd() to
      kvm_arch_flush_shadow_all().
      
      Cc: <stable@vger.kernel.org> # 3.9+
      Tested-by: default avatarItaru Kitayama <itaru.kitayama@riken.jp>
      Reported-by: default avatarItaru Kitayama <itaru.kitayama@riken.jp>
      Reported-by: default avatarJames Morse <james.morse@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      323d5348
    • Clemens Gruber's avatar
      usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase · 32eb86c0
      Clemens Gruber authored
      [ Upstream commit 6f3c4fb6 ]
      
      Problems with the signal integrity of the high speed USB data lines or
      noise on reference ground lines can cause the i.MX6 USB controller to
      violate USB specs and exhibit unexpected behavior.
      
      It was observed that USBi_UI interrupts were triggered first and when
      isr_setup_status_phase was called, ci->status was NULL, which lead to a
      NULL pointer dereference kernel panic.
      
      This patch fixes the kernel panic, emits a warning once and returns
      -EPIPE to halt the device and let the host get stalled.
      It also adds a comment to point people, who are experiencing this issue,
      to their USB hardware design.
      
      Cc: <stable@vger.kernel.org> #4.1+
      Signed-off-by: default avatarClemens Gruber <clemens.gruber@pqgruber.com>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      32eb86c0
    • Lee Jones's avatar
      ARM: dts: STiH410: Handle interconnect clock required by EHCI/OHCI (USB) · 4bfeb588
      Lee Jones authored
      [ Upstream commit 7e9d2850 ]
      
      The STiH4{07,10} platform contains some interconnect clocks which are used
      by various IPs.  If this clock isn't handled correctly by ST's EHCI/OHCI
      drivers, their hub won't be found, the following error be shown and the
      result will be non-working USB:
      
        [   97.221963] hub 2-1:1.0: hub_ext_port_status failed (err = -110)
      
      Cc: stable@vger.kernel.org
      Tested-by: default avatarPeter Griffin <peter.griffin@linaro.org>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Acked-by: default avatarPatrice Chotard <patrice.chotard@st.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      4bfeb588
    • Takashi Iwai's avatar
      ALSA: rawmidi: Fix possible deadlock with virmidi registration · 1c33cc04
      Takashi Iwai authored
      [ Upstream commit 816f318b ]
      
      When a seq-virmidi driver is initialized, it registers a rawmidi
      instance with its callback to create an associated seq kernel client.
      Currently it's done throughly in rawmidi's register_mutex context.
      Recently it was found that this may lead to a deadlock another rawmidi
      device that is being attached with the sequencer is accessed, as both
      open with the same register_mutex.  This was actually triggered by
      syzkaller, as Dmitry Vyukov reported:
      
      ======================================================
       [ INFO: possible circular locking dependency detected ]
       4.8.0-rc1+ #11 Not tainted
       -------------------------------------------------------
       syz-executor/7154 is trying to acquire lock:
        (register_mutex#5){+.+.+.}, at: [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
      
       but task is already holding lock:
        (&grp->list_mutex){++++.+}, at: [<ffffffff850138bb>] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&grp->list_mutex){++++.+}:
          [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
          [<ffffffff863f6199>] down_read+0x49/0xc0 kernel/locking/rwsem.c:22
          [<     inline     >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681
          [<ffffffff85005c5e>] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822
          [<ffffffff85006e96>] > snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418
          [<ffffffff85012c52>] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101
          [<ffffffff84fff70a>] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297
          [<     inline     >] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383
          [<ffffffff8502d29f>] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450
          [<ffffffff84fd208c>] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645
          [<ffffffff84f816d3>] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164
          [<     inline     >] __snd_device_register sound/core/device.c:162
          [<ffffffff84f8235d>] snd_device_register_all+0xad/0x110 sound/core/device.c:212
          [<ffffffff84f7546f>] snd_card_register+0xef/0x6c0 sound/core/init.c:749
          [<ffffffff85040b7f>] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123
          [<ffffffff833ebf7b>] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564
          ......
      
       -> #0 (register_mutex#5){+.+.+.}:
          [<     inline     >] check_prev_add kernel/locking/lockdep.c:1829
          [<     inline     >] check_prevs_add kernel/locking/lockdep.c:1939
          [<     inline     >] validate_chain kernel/locking/lockdep.c:2266
          [<ffffffff814791f4>] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335
          [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
          [<     inline     >] __mutex_lock_common kernel/locking/mutex.c:521
          [<ffffffff863f0ef1>] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621
          [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
          [<ffffffff8502e7c7>] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188
          [<     inline     >] subscribe_port sound/core/seq/seq_ports.c:427
          [<ffffffff85013cc7>] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510
          [<ffffffff85015da9>] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579
          [<ffffffff850079b8>] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480
          [<ffffffff84ffe9e4>] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225
          [<ffffffff84ffeae8>] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440
          [<ffffffff85027664>] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375
          [<ffffffff85023d67>] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281
          [<ffffffff8501b0a8>] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274
          [<ffffffff85019d8a>] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
          [<ffffffff84f7040f>] soundcore_open+0x30f/0x640 sound/sound_core.c:639
          ......
      
       other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&grp->list_mutex);
                                      lock(register_mutex#5);
                                      lock(&grp->list_mutex);
         lock(register_mutex#5);
      
       *** DEADLOCK ***
      ======================================================
      
      The fix is to simply move the registration parts in
      snd_rawmidi_dev_register() to the outside of the register_mutex lock.
      The lock is needed only to manage the linked list, and it's not
      necessarily to cover the whole initialization process.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1c33cc04
    • Takashi Iwai's avatar
      ALSA: timer: Fix zero-division by continue of uninitialized instance · d14b394a
      Takashi Iwai authored
      [ Upstream commit 9f8a7658 ]
      
      When a user timer instance is continued without the explicit start
      beforehand, the system gets eventually zero-division error like:
      
        divide error: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
        CPU: 1 PID: 27320 Comm: syz-executor Not tainted 4.8.0-rc3-next-20160825+ #8
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
         task: ffff88003c9b2280 task.stack: ffff880027280000
         RIP: 0010:[<ffffffff858e1a6c>]  [<     inline     >] ktime_divns include/linux/ktime.h:195
         RIP: 0010:[<ffffffff858e1a6c>]  [<ffffffff858e1a6c>] snd_hrtimer_callback+0x1bc/0x3c0 sound/core/hrtimer.c:62
        Call Trace:
         <IRQ>
         [<     inline     >] __run_hrtimer kernel/time/hrtimer.c:1238
         [<ffffffff81504335>] __hrtimer_run_queues+0x325/0xe70 kernel/time/hrtimer.c:1302
         [<ffffffff81506ceb>] hrtimer_interrupt+0x18b/0x420 kernel/time/hrtimer.c:1336
         [<ffffffff8126d8df>] local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:933
         [<ffffffff86e13056>] smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:957
         [<ffffffff86e1210c>] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:487
         <EOI>
         .....
      
      Although a similar issue was spotted and a fix patch was merged in
      commit [6b760bb2: ALSA: timer: fix division by zero after
      SNDRV_TIMER_IOCTL_CONTINUE], it seems covering only a part of
      iceberg.
      
      In this patch, we fix the issue a bit more drastically.  Basically the
      continue of an uninitialized timer is supposed to be a fresh start, so
      we do it for user timers.  For the direct snd_timer_continue() call,
      there is no way to pass the initial tick value, so we kick out for the
      uninitialized case.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      d14b394a
    • Takashi Iwai's avatar
      ALSA: timer: Call notifier in the same spinlock · bc84b389
      Takashi Iwai authored
      [ Upstream commit f65e0d29 ]
      
      snd_timer_notify1() is called outside the spinlock and it retakes the
      lock after the unlock.  This is rather racy, and it's safer to move
      snd_timer_notify() call inside the main spinlock.
      
      The patch also contains a slight refactoring / cleanup of the code.
      Now all start/stop/continue/pause look more symmetric and a bit better
      readable.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      bc84b389
  2. 02 Oct, 2016 24 commits
    • Mathias Nyman's avatar
      xhci: fix null pointer dereference in stop command timeout function · 631f0633
      Mathias Nyman authored
      [ Upstream commit bcf42aa6 ]
      
      The stop endpoint command has its own 5 second timeout timer.
      If the timeout function is triggered between USB3 and USB2 host
      removal it will try to call usb_hc_died(xhci_to_hcd(xhci)->primary_hcd)
      
      the ->primary_hcd will be set to NULL at USB3 hcd removal.
      
      Fix this by first checking if the PCI host is being removed, and
      also by using only xhci_to_hcd() as it will always return the primary
      hcd.
      
      CC: <stable@vger.kernel.org>
      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 avatarSasha Levin <alexander.levin@verizon.com>
      631f0633
    • Paul Mackerras's avatar
      powerpc/mm: Don't alias user region to other regions below PAGE_OFFSET · 7b6ea253
      Paul Mackerras authored
      [ Upstream commit f077aaf0 ]
      
      In commit c60ac569 ("powerpc: Update kernel VSID range", 2013-03-13)
      we lost a check on the region number (the top four bits of the effective
      address) for addresses below PAGE_OFFSET.  That commit replaced a check
      that the top 18 bits were all zero with a check that bits 46 - 59 were
      zero (performed for all addresses, not just user addresses).
      
      This means that userspace can access an address like 0x1000_0xxx_xxxx_xxxx
      and we will insert a valid SLB entry for it.  The VSID used will be the
      same as if the top 4 bits were 0, but the page size will be some random
      value obtained by indexing beyond the end of the mm_ctx_high_slices_psize
      array in the paca.  If that page size is the same as would be used for
      region 0, then userspace just has an alias of the region 0 space.  If the
      page size is different, then no HPTE will be found for the access, and
      the process will get a SIGSEGV (since hash_page_mm() will refuse to create
      a HPTE for the bogus address).
      
      The access beyond the end of the mm_ctx_high_slices_psize can be at most
      5.5MB past the array, and so will be in RAM somewhere.  Since the access
      is a load performed in real mode, it won't fault or crash the kernel.
      At most this bug could perhaps leak a little bit of information about
      blocks of 32 bytes of memory located at offsets of i * 512kB past the
      paca->mm_ctx_high_slices_psize array, for 1 <= i <= 11.
      
      Fixes: c60ac569 ("powerpc: Update kernel VSID range")
      Cc: stable@vger.kernel.org # v3.9+
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Reviewed-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7b6ea253
    • Ard Biesheuvel's avatar
      crypto: cryptd - initialize child shash_desc on import · b8e51107
      Ard Biesheuvel authored
      [ Upstream commit 0bd22235 ]
      
      When calling .import() on a cryptd ahash_request, the structure members
      that describe the child transform in the shash_desc need to be initialized
      like they are when calling .init()
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b8e51107
    • Wei Yongjun's avatar
      ipv6: addrconf: fix dev refcont leak when DAD failed · 81e6db1b
      Wei Yongjun authored
      [ Upstream commit 751eb6b6 ]
      
      In general, when DAD detected IPv6 duplicate address, ifp->state
      will be set to INET6_IFADDR_STATE_ERRDAD and DAD is stopped by a
      delayed work, the call tree should be like this:
      
      ndisc_recv_ns
        -> addrconf_dad_failure        <- missing ifp put
           -> addrconf_mod_dad_work
             -> schedule addrconf_dad_work()
               -> addrconf_dad_stop()  <- missing ifp hold before call it
      
      addrconf_dad_failure() called with ifp refcont holding but not put.
      addrconf_dad_work() call addrconf_dad_stop() without extra holding
      refcount. This will not cause any issue normally.
      
      But the race between addrconf_dad_failure() and addrconf_dad_work()
      may cause ifp refcount leak and netdevice can not be unregister,
      dmesg show the following messages:
      
      IPv6: eth0: IPv6 duplicate address fe80::XX:XXXX:XXXX:XX detected!
      ...
      unregister_netdevice: waiting for eth0 to become free. Usage count = 1
      
      Cc: stable@vger.kernel.org
      Fixes: c15b1cca ("ipv6: move DAD and addrconf_verify processing
      to workqueue")
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      81e6db1b
    • Chris Mason's avatar
      Btrfs: remove root_log_ctx from ctx list before btrfs_sync_log returns · 12ebbc22
      Chris Mason authored
      [ Upstream commit cbd60aa7 ]
      
      We use a btrfs_log_ctx structure to pass information into the
      tree log commit, and get error values out.  It gets added to a per
      log-transaction list which we walk when things go bad.
      
      Commit d1433deb added an optimization to skip waiting for the log
      commit, but didn't take root_log_ctx out of the list.  This
      patch makes sure we remove things before exiting.
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Fixes: d1433deb
      cc: stable@vger.kernel.org # 3.15+
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      12ebbc22
    • Jan Leupold's avatar
      drm: atmel-hlcdc: Fix vertical scaling · c2aca6bb
      Jan Leupold authored
      [ Upstream commit d31ed3f0 ]
      
      The code is applying the same scaling for the X and Y components,
      thus making the scaling feature only functional when both components
      have the same scaling factor.
      
      Do the s/_w/_h/ replacement where appropriate to fix vertical scaling.
      Signed-off-by: default avatarJan Leupold <leupold@rsi-elektrotechnik.de>
      Fixes: 1a396789 ("drm: add Atmel HLCDC Display Controller support")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c2aca6bb
    • Miklos Szeredi's avatar
      ovl: fix workdir creation · 12c68a9c
      Miklos Szeredi authored
      [ Upstream commit e1ff3dd1 ]
      
      Workdir creation fails in latest kernel.
      
      Fix by allowing EOPNOTSUPP as a valid return value from
      vfs_removexattr(XATTR_NAME_POSIX_ACL_*).  Upper filesystem may not support
      ACL and still be perfectly able to support overlayfs.
      Reported-by: default avatarMartin Ziegler <ziegler@uni-freiburg.de>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: c11b9fdd ("ovl: remove posix_acl_default from workdir")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      12c68a9c
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: fix clearing the {BRDY,BEMP}STS condition · 8af2ce07
      Yoshihiro Shimoda authored
      [ Upstream commit 519d8bd4 ]
      
      The previous driver is possible to stop the transfer wrongly.
      For example:
       1) An interrupt happens, but not BRDY interruption.
       2) Read INTSTS0. And than state->intsts0 is not set to BRDY.
       3) BRDY is set to 1 here.
       4) Read BRDYSTS.
       5) Clear the BRDYSTS. And then. the BRDY is cleared wrongly.
      
      Remarks:
       - The INTSTS0.BRDY is read only.
        - If any bits of BRDYSTS are set to 1, the BRDY is set to 1.
        - If BRDYSTS is 0, the BRDY is set to 0.
      
      So, this patch adds condition to avoid such situation. (And about
      NRDYSTS, this is not used for now. But, avoiding any side effects,
      this patch doesn't touch it.)
      
      Fixes: d5c6a1e0 ("usb: renesas_usbhs: fixup interrupt status clear method")
      Cc: <stable@vger.kernel.org> # v3.8+
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8af2ce07
    • Balbir Singh's avatar
      sched/core: Fix a race between try_to_wake_up() and a woken up task · 431d09f2
      Balbir Singh authored
      [ Upstream commit 135e8c92 ]
      
      The origin of the issue I've seen is related to
      a missing memory barrier between check for task->state and
      the check for task->on_rq.
      
      The task being woken up is already awake from a schedule()
      and is doing the following:
      
      	do {
      		schedule()
      		set_current_state(TASK_(UN)INTERRUPTIBLE);
      	} while (!cond);
      
      The waker, actually gets stuck doing the following in
      try_to_wake_up():
      
      	while (p->on_cpu)
      		cpu_relax();
      
      Analysis:
      
      The instance I've seen involves the following race:
      
       CPU1					CPU2
      
       while () {
         if (cond)
           break;
         do {
           schedule();
           set_current_state(TASK_UN..)
         } while (!cond);
      					wakeup_routine()
      					  spin_lock_irqsave(wait_lock)
         raw_spin_lock_irqsave(wait_lock)	  wake_up_process()
       }					  try_to_wake_up()
       set_current_state(TASK_RUNNING);	  ..
       list_del(&waiter.list);
      
      CPU2 wakes up CPU1, but before it can get the wait_lock and set
      current state to TASK_RUNNING the following occurs:
      
       CPU3
       wakeup_routine()
       raw_spin_lock_irqsave(wait_lock)
       if (!list_empty)
         wake_up_process()
         try_to_wake_up()
         raw_spin_lock_irqsave(p->pi_lock)
         ..
         if (p->on_rq && ttwu_wakeup())
         ..
         while (p->on_cpu)
           cpu_relax()
         ..
      
      CPU3 tries to wake up the task on CPU1 again since it finds
      it on the wait_queue, CPU1 is spinning on wait_lock, but immediately
      after CPU2, CPU3 got it.
      
      CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and
      the task is spinning on the wait_lock. Interestingly since p->on_rq
      is checked under pi_lock, I've noticed that try_to_wake_up() finds
      p->on_rq to be 0. This was the most confusing bit of the analysis,
      but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq
      check is not reliable without this fix IMHO. The race is visible
      (based on the analysis) only when ttwu_queue() does a remote wakeup
      via ttwu_queue_remote. In which case the p->on_rq change is not
      done uder the pi_lock.
      
      The result is that after a while the entire system locks up on
      the raw_spin_irqlock_save(wait_lock) and the holder spins infintely
      
      Reproduction of the issue:
      
      The issue can be reproduced after a long run on my system with 80
      threads and having to tweak available memory to very low and running
      memory stress-ng mmapfork test. It usually takes a long time to
      reproduce. I am trying to work on a test case that can reproduce
      the issue faster, but thats work in progress. I am still testing the
      changes on my still in a loop and the tests seem OK thus far.
      
      Big thanks to Benjamin and Nick for helping debug this as well.
      Ben helped catch the missing barrier, Nick caught every missing
      bit in my theory.
      Signed-off-by: default avatarBalbir Singh <bsingharora@gmail.com>
      [ Updated comment to clarify matching barriers. Many
        architectures do not have a full barrier in switch_to()
        so that cannot be relied upon. ]
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nicholas Piggin <nicholas.piggin@gmail.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/e02cce7b-d9ca-1ad0-7a61-ea97c7582b37@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      431d09f2
    • Linus Walleij's avatar
      iio: accel: kxsd9: Fix scaling bug · 1ea35b9f
      Linus Walleij authored
      [ Upstream commit 307fe9dd ]
      
      All the scaling of the KXSD9 involves multiplication with a
      fraction number < 1.
      
      However the scaling value returned from IIO_INFO_SCALE was
      unpredictable as only the micros of the value was assigned, and
      not the integer part, resulting in scaling like this:
      
      $cat in_accel_scale
      -1057462640.011978
      
      Fix this by assigning zero to the integer part.
      
      Cc: stable@vger.kernel.org
      Tested-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      1ea35b9f
    • Vegard Nossum's avatar
      ALSA: timer: fix NULL pointer dereference in read()/ioctl() race · 193eb8f1
      Vegard Nossum authored
      [ Upstream commit 11749e08 ]
      
      I got this with syzkaller:
      
          ==================================================================
          BUG: KASAN: null-ptr-deref on address 0000000000000020
          Read of size 32 by task syz-executor/22519
          CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2
          014
           0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90
           ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80
           ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68
          Call Trace:
           [<ffffffff81f9f141>] dump_stack+0x83/0xb2
           [<ffffffff8161fe3f>] kasan_report_error+0x41f/0x4c0
           [<ffffffff8161ff74>] kasan_report+0x34/0x40
           [<ffffffff82c84b54>] ? snd_timer_user_read+0x554/0x790
           [<ffffffff8161e79e>] check_memory_region+0x13e/0x1a0
           [<ffffffff8161e9c1>] kasan_check_read+0x11/0x20
           [<ffffffff82c84b54>] snd_timer_user_read+0x554/0x790
           [<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
           [<ffffffff817d0831>] ? proc_fault_inject_write+0x1c1/0x250
           [<ffffffff817d0670>] ? next_tgid+0x2a0/0x2a0
           [<ffffffff8127c278>] ? do_group_exit+0x108/0x330
           [<ffffffff8174653a>] ? fsnotify+0x72a/0xca0
           [<ffffffff81674dfe>] __vfs_read+0x10e/0x550
           [<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
           [<ffffffff81674cf0>] ? do_sendfile+0xc50/0xc50
           [<ffffffff81745e10>] ? __fsnotify_update_child_dentry_flags+0x60/0x60
           [<ffffffff8143fec6>] ? kcov_ioctl+0x56/0x190
           [<ffffffff81e5ada2>] ? common_file_perm+0x2e2/0x380
           [<ffffffff81746b0e>] ? __fsnotify_parent+0x5e/0x2b0
           [<ffffffff81d93536>] ? security_file_permission+0x86/0x1e0
           [<ffffffff816728f5>] ? rw_verify_area+0xe5/0x2b0
           [<ffffffff81675355>] vfs_read+0x115/0x330
           [<ffffffff81676371>] SyS_read+0xd1/0x1a0
           [<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
           [<ffffffff82001c2c>] ? __this_cpu_preempt_check+0x1c/0x20
           [<ffffffff8150455a>] ? __context_tracking_exit.part.4+0x3a/0x1e0
           [<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
           [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
           [<ffffffff810052fc>] ? syscall_return_slowpath+0x16c/0x1d0
           [<ffffffff83c3276a>] entry_SYSCALL64_slow_path+0x25/0x25
          ==================================================================
      
      There are a couple of problems that I can see:
      
       - ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets
         tu->queue/tu->tqueue to NULL on memory allocation failure, so read()
         would get a NULL pointer dereference like the above splat
      
       - the same ioctl() can free tu->queue/to->tqueue which means read()
         could potentially see (and dereference) the freed pointer
      
      We can fix both by taking the ioctl_lock mutex when dereferencing
      ->queue/->tqueue, since that's always held over all the ioctl() code.
      
      Just looking at the code I find it likely that there are more problems
      here such as tu->qhead pointing outside the buffer if the size is
      changed concurrently using SNDRV_TIMER_IOCTL_PARAMS.
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      193eb8f1
    • Takashi Sakamoto's avatar
      ALSA: fireworks: accessing to user space outside spinlock · 854a40fa
      Takashi Sakamoto authored
      [ Upstream commit 6b1ca4bc ]
      
      In hwdep interface of fireworks driver, accessing to user space is in a
      critical section with disabled local interrupt. Depending on architecture,
      accessing to user space can cause page fault exception. Then local
      processor stores machine status and handles the synchronous event. A
      handler corresponding to the event can call task scheduler to wait for
      preparing pages. In a case of usage of single core processor, the state to
      disable local interrupt is worse because it don't handle usual interrupts
      from hardware.
      
      This commit fixes this bug, performing the accessing outside spinlock. This
      commit also gives up counting the number of queued response messages to
      simplify ring-buffer management.
      Reported-by: default avatarVaishali Thakkar <vaishali.thakkar@oracle.com>
      Cc: stable@vger.kernel.org
      Fixes: 555e8a8f('ALSA: fireworks: Add command/response functionality into hwdep interface')
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      854a40fa
    • Anson Huang's avatar
      ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx · 82ae68a8
      Anson Huang authored
      [ Upstream commit 8aade778 ]
      
      i.MX6SX has bypass PMIC ready function, as this function
      is normally NOT enabled on the board design, so we need
      to bypass the PMIC ready pin check during DSM mode resume
      flow, otherwise, the internal DSM resume logic will be
      waiting for this signal to be ready forever and cause
      resume fail.
      Signed-off-by: default avatarAnson Huang <Anson.Huang@nxp.com>
      Fixes: ff843d62 ("ARM: imx: add suspend support for i.mx6sx")
      Cc: <stable@vger.kernel.org>
      Tested-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      82ae68a8
    • Kai-Heng Feng's avatar
      ALSA: hda - Enable subwoofer on Dell Inspiron 7559 · 6558ce65
      Kai-Heng Feng authored
      [ Upstream commit fd06c77e ]
      
      The subwoofer on Inspiron 7559 was disabled originally.
      Applying a pin fixup to node 0x1b can enable it and make it work.
      
      Old pin: 0x411111f0
      New pin: 0x90170151
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6558ce65
    • Ken Lin's avatar
      ALSA: usb-audio: Add sample rate inquiry quirk for B850V3 CP2114 · 7b7cc699
      Ken Lin authored
      [ Upstream commit 83d9956b ]
      
      Avoid getting sample rate on B850V3 CP2114 as it is unsupported and
      causes noisy "current rate is different from the runtime rate" messages
      when playback starts.
      Signed-off-by: default avatarKen Lin <ken.lin@advantech.com.tw>
      Signed-off-by: default avatarAkshay Bhat <akshay.bhat@timesys.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7b7cc699
    • Vegard Nossum's avatar
      ALSA: timer: fix NULL pointer dereference on memory allocation failure · 6138d59d
      Vegard Nossum authored
      [ Upstream commit 8ddc0563 ]
      
      I hit this with syzkaller:
      
          kasan: CONFIG_KASAN_INLINE enabled
          kasan: GPF could be caused by NULL-ptr deref or user memory access
          general protection fault: 0000 [#1] PREEMPT SMP KASAN
          CPU: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
          task: ffff88011278d600 task.stack: ffff8801120c0000
          RIP: 0010:[<ffffffff82c8ba07>]  [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
          RSP: 0018:ffff8801120c7a60  EFLAGS: 00010006
          RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007
          RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048
          RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790
          R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980
          R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286
          FS:  00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0
          Stack:
           ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0
           ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000
           ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0
          Call Trace:
           [<ffffffff82c81ab1>] snd_timer_start1+0x331/0x670
           [<ffffffff82c85bfd>] snd_timer_start+0x5d/0xa0
           [<ffffffff82c8795e>] snd_timer_user_ioctl+0x88e/0x2830
           [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
           [<ffffffff8132762f>] ? put_prev_entity+0x108f/0x21a0
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
           [<ffffffff813510af>] ? cpuacct_account_field+0x12f/0x1a0
           [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
           [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
           [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
           [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
           [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
           [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
           [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
           [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
           [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
           [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
          Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46
          RIP  [<ffffffff82c8ba07>] snd_hrtimer_start+0x77/0x100
           RSP <ffff8801120c7a60>
          ---[ end trace 5955b08db7f2b029 ]---
      
      This can happen if snd_hrtimer_open() fails to allocate memory and
      returns an error, which is currently not checked by snd_timer_open():
      
          ioctl(SNDRV_TIMER_IOCTL_SELECT)
           - snd_timer_user_tselect()
      	- snd_timer_close()
      	   - snd_hrtimer_close()
      	      - (struct snd_timer *) t->private_data = NULL
              - snd_timer_open()
                 - snd_hrtimer_open()
                    - kzalloc() fails; t->private_data is still NULL
      
          ioctl(SNDRV_TIMER_IOCTL_START)
           - snd_timer_user_start()
      	- snd_timer_start()
      	   - snd_timer_start1()
      	      - snd_hrtimer_start()
      		- t->private_data == NULL // boom
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      6138d59d
    • Vegard Nossum's avatar
      ALSA: timer: fix division by zero after SNDRV_TIMER_IOCTL_CONTINUE · 2350481b
      Vegard Nossum authored
      [ Upstream commit 6b760bb2 ]
      
      I got this:
      
          divide error: 0000 [#1] PREEMPT SMP KASAN
          CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
          task: ffff8801120a9580 task.stack: ffff8801120b0000
          RIP: 0010:[<ffffffff82c8bd9a>]  [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
          RSP: 0018:ffff88011aa87da8  EFLAGS: 00010006
          RAX: 0000000000004f76 RBX: ffff880112655e88 RCX: 0000000000000000
          RDX: 0000000000000000 RSI: ffff880112655ea0 RDI: 0000000000000001
          RBP: ffff88011aa87e00 R08: ffff88013fff905c R09: ffff88013fff9048
          R10: ffff88013fff9050 R11: 00000001050a7b8c R12: ffff880114778a00
          R13: ffff880114778ab4 R14: ffff880114778b30 R15: 0000000000000000
          FS:  00007f071647c700(0000) GS:ffff88011aa80000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 0000000000603001 CR3: 0000000112021000 CR4: 00000000000006e0
          Stack:
           0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76
           ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0
           00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0
          Call Trace:
           <IRQ>
           [<ffffffff813abce7>] __hrtimer_run_queues+0x347/0xa00
           [<ffffffff82c8bbc0>] ? snd_hrtimer_close+0x130/0x130
           [<ffffffff813ab9a0>] ? retrigger_next_event+0x1b0/0x1b0
           [<ffffffff813ae1a6>] ? hrtimer_interrupt+0x136/0x4b0
           [<ffffffff813ae220>] hrtimer_interrupt+0x1b0/0x4b0
           [<ffffffff8120f91e>] local_apic_timer_interrupt+0x6e/0xf0
           [<ffffffff81227ad3>] ? kvm_guest_apic_eoi_write+0x13/0xc0
           [<ffffffff83c35086>] smp_apic_timer_interrupt+0x76/0xa0
           [<ffffffff83c3416c>] apic_timer_interrupt+0x8c/0xa0
           <EOI>
           [<ffffffff83c3239c>] ? _raw_spin_unlock_irqrestore+0x2c/0x60
           [<ffffffff82c8185d>] snd_timer_start1+0xdd/0x670
           [<ffffffff82c87015>] snd_timer_continue+0x45/0x80
           [<ffffffff82c88100>] snd_timer_user_ioctl+0x1030/0x2830
           [<ffffffff8159f3a0>] ? __follow_pte.isra.49+0x430/0x430
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff815a26fa>] ? do_wp_page+0x3aa/0x1c90
           [<ffffffff815aa4f8>] ? handle_mm_fault+0xbc8/0x27f0
           [<ffffffff815a9930>] ? __pmd_alloc+0x370/0x370
           [<ffffffff82c870d0>] ? snd_timer_pause+0x80/0x80
           [<ffffffff816b0733>] do_vfs_ioctl+0x193/0x1050
           [<ffffffff816b05a0>] ? ioctl_preallocate+0x200/0x200
           [<ffffffff81002f2f>] ? syscall_trace_enter+0x3cf/0xdb0
           [<ffffffff815045ba>] ? __context_tracking_exit.part.4+0x9a/0x1e0
           [<ffffffff81002b60>] ? exit_to_usermode_loop+0x190/0x190
           [<ffffffff82001a97>] ? check_preemption_disabled+0x37/0x1e0
           [<ffffffff81d93889>] ? security_file_ioctl+0x89/0xb0
           [<ffffffff816b167f>] SyS_ioctl+0x8f/0xc0
           [<ffffffff816b15f0>] ? do_vfs_ioctl+0x1050/0x1050
           [<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
           [<ffffffff83c32b2a>] entry_SYSCALL64_slow_path+0x25/0x25
          Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 <48> f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00
          RIP  [<ffffffff82c8bd9a>] snd_hrtimer_callback+0x1da/0x3f0
           RSP <ffff88011aa87da8>
          ---[ end trace 6aa380f756a21074 ]---
      
      The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a
      completely new/unused timer -- it will have ->sticks == 0, which causes a
      divide by 0 in snd_hrtimer_callback().
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      2350481b
    • Simon Baatz's avatar
      ARM: kirkwood: ib62x0: fix size of u-boot environment partition · 8773752e
      Simon Baatz authored
      [ Upstream commit a7789378 ]
      
      Commit 148c274e ("ARM: kirkwood: ib62x0: add u-boot environment
      partition") split the "u-boot" partition into "u-boot" and "u-boot
      environment".  However, instead of the size of the environment, an offset
      was given, resulting in overlapping partitions.
      Signed-off-by: default avatarSimon Baatz <gmbnomis@gmail.com>
      Fixes: 148c274e ("ARM: kirkwood: ib62x0: add u-boot environment partition")
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Luka Perkov <luka@openwrt.org>
      Cc: stable@vger.kernel.org # 3.13+
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      8773752e
    • Miklos Szeredi's avatar
      fuse: direct-io: don't dirty ITER_BVEC pages · 7933dd87
      Miklos Szeredi authored
      [ Upstream commit 8fba54ae ]
      
      When reading from a loop device backed by a fuse file it deadlocks on
      lock_page().
      
      This is because the page is already locked by the read() operation done on
      the loop device.  In this case we don't want to either lock the page or
      dirty it.
      
      So do what fs/direct-io.c does: only dirty the page for ITER_IOVEC vectors.
      Reported-by: default avatarSheng Yang <sheng@yasker.org>
      Fixes: aa4d8616 ("block: loop: switch to VFS ITER_BVEC")
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: <stable@vger.kernel.org> # v4.1+
      Reviewed-by: default avatarSheng Yang <sheng@yasker.org>
      Reviewed-by: default avatarAshish Samant <ashish.samant@oracle.com>
      Tested-by: default avatarSheng Yang <sheng@yasker.org>
      Tested-by: default avatarAshish Samant <ashish.samant@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      7933dd87
    • Felix Fietkau's avatar
      ath9k: fix using sta->drv_priv before initializing it · bb5c68e0
      Felix Fietkau authored
      [ Upstream commit 7711aaf0 ]
      
      A station pointer can be passed to the driver on tx, before it has been
      marked as associated. Since ath9k_sta_state was initializing the entry
      too late, it resulted in some spurious crashes.
      
      Fixes: df3c6eb3 ("ath9k: Use sta_state() callback")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      bb5c68e0
    • Pawel Moll's avatar
      bus: arm-ccn: Fix XP watchpoint settings bitmask · c3e7a0e5
      Pawel Moll authored
      [ Upstream commit b928466b ]
      
      The code setting XP watchpoint comparator and mask registers should, in
      order to be fully compliant with specification, zero one or more most
      significant bits of each field. In both L cases it means zeroing bit 63.
      The bitmask doing this was wrong, though, zeroing bit 60 instead.
      Fortunately, due to a lucky coincidence, this turned out to be fairly
      innocent with the existing hardware.
      
      Fixed now.
      
      Cc: stable@vger.kernel.org # 3.17+
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      c3e7a0e5
    • Pawel Moll's avatar
      bus: arm-ccn: Do not attempt to configure XPs for cycle counter · b9d45ce3
      Pawel Moll authored
      [ Upstream commit b7c1beb2 ]
      
      Fuzzing the CCN perf driver revealed a small but definitely dangerous
      mistake in the event setup code. When a cycle counter is requested, the
      driver should not reconfigure the events bus at all, otherwise it will
      corrupt (in most but the simplest cases) its configuration and may end
      up accessing XP array out of its bounds and corrupting control
      registers.
      Reported-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: stable@vger.kernel.org # 3.17+
      Signed-off-by: default avatarPawel Moll <pawel.moll@arm.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      b9d45ce3
    • Tyrel Datwyler's avatar
      scsi: fix upper bounds check of sense key in scsi_sense_key_string() · 0dd4c68f
      Tyrel Datwyler authored
      [ Upstream commit a87eeb90 ]
      
      Commit 655ee63c ("scsi constants: command, sense key + additional
      sense string") added a "Completed" sense string with key 0xF to
      snstext[], but failed to updated the upper bounds check of the sense key
      in scsi_sense_key_string().
      
      Fixes: 655ee63c ("[SCSI] scsi constants: command, sense key + additional sense strings")
      Cc: <stable@vger.kernel.org> # v3.12+
      Signed-off-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      0dd4c68f
    • Johannes Berg's avatar
      Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel" · cfad3a5a
      Johannes Berg authored
      [ Upstream commit 4d0bd46a ]
      
      This reverts commit 3d5fdff4.
      
      Ben Hutchings pointed out that the commit isn't safe since it assumes
      that the structure used by the driver is iw_point, when in fact there's
      no way to know about that.
      
      Fortunately, the only driver in the tree that ever runs this code path
      is the wilc1000 staging driver, so it doesn't really matter.
      
      Clearly I should have investigated this better before applying, sorry.
      Reported-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: stable@vger.kernel.org [though I guess it doesn't matter much]
      Fixes: 3d5fdff4 ("wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      cfad3a5a