1. 29 Jun, 2017 15 commits
    • Raju Rangoju's avatar
      cxgb4: notify uP to route ctrlq compl to rdma rspq · cdf300d6
      Raju Rangoju authored
      commit dec6b331 upstream.
      
      During the module initialisation there is a possible race
      (basically race between uld and lld) where neither the uld
      nor lld notifies the uP about where to route the ctrl queue
      completions. LLD skips notifying uP as the rdma queues were
      not created by then (will leave it to ULD to notify the uP).
      As the ULD comes up, it also skips notifying the uP as the
      flag FULL_INIT_DONE is not set yet (ULD assumes that the
      interface is not up yet).
      
      Consequently, this race between uld and lld leaves uP
      unnotified about where to send the ctrl queue completions
      to, leading to iwarp RI_RES WR failure.
      
      Here is the race:
      
      CPU 0                                   CPU1
      
      - allocates nic rx queus
      - t4_sge_alloc_ctrl_txq()
      (if rdma rsp queues exists,
      tell uP to route ctrl queue
      compl to rdma rspq)
                                      - acquires the mutex_lock
                                      - allocates rdma response queues
                                      - if FULL_INIT_DONE set,
                                        tell uP to route ctrl queue compl
                                        to rdma rspq
                                      - relinquishes mutex_lock
      - acquires the mutex_lock
      - enable_rx()
      - set FULL_INIT_DONE
      - relinquishes mutex_lock
      
      This patch fixes the above issue.
      
      Fixes: e7519f99('cxgb4: avoid enabling napi twice to the same queue')
      Signed-off-by: default avatarRaju Rangoju <rajur@chelsio.com>
      Acked-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cdf300d6
    • Pavel Shilovsky's avatar
      CIFS: Improve readdir verbosity · fb6dc831
      Pavel Shilovsky authored
      commit dcd87838 upstream.
      
      Downgrade the loglevel for SMB2 to prevent filling the log
      with messages if e.g. readdir was interrupted. Also make SMB2
      and SMB1 codepaths do the same logging during readdir.
      Signed-off-by: default avatarPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb6dc831
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Context-switch EBB registers properly · 2f1527e3
      Paul Mackerras authored
      commit ca8efa1d upstream.
      
      This adds code to save the values of three SPRs (special-purpose
      registers) used by userspace to control event-based branches (EBBs),
      which are essentially interrupts that get delivered directly to
      userspace.  These registers are loaded up with guest values when
      entering the guest, and their values are saved when exiting the
      guest, but we were not saving the host values and restoring them
      before going back to userspace.
      
      On POWER8 this would only affect userspace programs which explicitly
      request the use of EBBs and also use the KVM_RUN ioctl, since the
      only source of EBBs on POWER8 is the PMU, and there is an explicit
      enable bit in the PMU registers (and those PMU registers do get
      properly context-switched between host and guest).  On POWER9 there
      is provision for externally-generated EBBs, and these are not subject
      to the control in the PMU registers.
      
      Since these registers only affect userspace, we can save them when
      we first come in from userspace and restore them before returning to
      userspace, rather than saving/restoring the host values on every
      guest entry/exit.  Similarly, we don't need to worry about their
      values on offline secondary threads since they execute in the context
      of the idle task, which never executes in userspace.
      
      Fixes: b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f1527e3
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Preserve userspace HTM state properly · 468aa930
      Paul Mackerras authored
      commit 46a704f8 upstream.
      
      If userspace attempts to call the KVM_RUN ioctl when it has hardware
      transactional memory (HTM) enabled, the values that it has put in the
      HTM-related SPRs TFHAR, TFIAR and TEXASR will get overwritten by
      guest values.  To fix this, we detect this condition and save those
      SPR values in the thread struct, and disable HTM for the task.  If
      userspace goes to access those SPRs or the HTM facility in future,
      a TM-unavailable interrupt will occur and the handler will reload
      those SPRs and re-enable HTM.
      
      If userspace has started a transaction and suspended it, we would
      currently lose the transactional state in the guest entry path and
      would almost certainly get a "TM Bad Thing" interrupt, which would
      cause the host to crash.  To avoid this, we detect this case and
      return from the KVM_RUN ioctl with an EINVAL error, with the KVM
      exit reason set to KVM_EXIT_FAIL_ENTRY.
      
      Fixes: b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      468aa930
    • Heiko Carstens's avatar
      KVM: s390: gaccess: fix real-space designation asce handling for gmap shadows · df3a787b
      Heiko Carstens authored
      commit addb63c1 upstream.
      
      For real-space designation asces the asce origin part is only a token.
      The asce token origin must not be used to generate an effective
      address for storage references. This however is erroneously done
      within kvm_s390_shadow_tables().
      
      Furthermore within the same function the wrong parts of virtual
      addresses are used to generate a corresponding real address
      (e.g. the region second index is used as region first index).
      
      Both of the above can result in incorrect address translations. Only
      for real space designations with a token origin of zero and addresses
      below one megabyte the translation was correct.
      
      Furthermore replace a "!asce.r" statement with a "!*fake" statement to
      make it more obvious that a specific condition has nothing to do with
      the architecture, but with the fake handling of real space designations.
      
      Fixes: 3218f709 ("s390/mm: support real-space for gmap shadows")
      Cc: David Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Reviewed-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      df3a787b
    • Kan Liang's avatar
      perf/x86/intel: Add 1G DTLB load/store miss support for SKL · 5220378b
      Kan Liang authored
      commit fb3a5055 upstream.
      
      Current DTLB load/store miss events (0x608/0x649) only counts 4K,2M and
      4M page size.
      Need to extend the events to support any page size (4K/2M/4M/1G).
      
      The complete DTLB load/store miss events are:
      
        DTLB_LOAD_MISSES.WALK_COMPLETED		0xe08
        DTLB_STORE_MISSES.WALK_COMPLETED		0xe49
      Signed-off-by: default avatarKan Liang <Kan.liang@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: eranian@google.com
      Link: http://lkml.kernel.org/r/20170619142609.11058-1-kan.liang@intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5220378b
    • Ilya Matveychikov's avatar
      lib/cmdline.c: fix get_options() overflow while parsing ranges · 7c679fe7
      Ilya Matveychikov authored
      commit a91e0f68 upstream.
      
      When using get_options() it's possible to specify a range of numbers,
      like 1-100500.  The problem is that it doesn't track array size while
      calling internally to get_range() which iterates over the range and
      fills the memory with numbers.
      
      Link: http://lkml.kernel.org/r/2613C75C-B04D-4BFF-82A6-12F97BA0F620@gmail.comSigned-off-by: default avatarIlya V. Matveychikov <matvejchikov@gmail.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c679fe7
    • NeilBrown's avatar
      autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL · bc6eecff
      NeilBrown authored
      commit 9fa4eb8e upstream.
      
      If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL ioctl,
      autofs4_d_automount() will return
      
         ERR_PTR(status)
      
      with that status to follow_automount(), which will then dereference an
      invalid pointer.
      
      So treat a positive status the same as zero, and map to ENOENT.
      
      See comment in systemd src/core/automount.c::automount_send_ready().
      
      Link: http://lkml.kernel.org/r/871sqwczx5.fsf@notabene.neil.brown.nameSigned-off-by: default avatarNeilBrown <neilb@suse.com>
      Cc: Ian Kent <raven@themaw.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc6eecff
    • Ravi Bangoria's avatar
      powerpc/perf: Fix oops when kthread execs user process · 4b660fcb
      Ravi Bangoria authored
      commit bf05fc25 upstream.
      
      When a kthread calls call_usermodehelper() the steps are:
        1. allocate current->mm
        2. load_elf_binary()
        3. populate current->thread.regs
      
      While doing this, interrupts are not disabled. If there is a perf
      interrupt in the middle of this process (i.e. step 1 has completed
      but not yet reached to step 3) and if perf tries to read userspace
      regs, kernel oops with following log:
      
        Unable to handle kernel paging request for data at address 0x00000000
        Faulting instruction address: 0xc0000000000da0fc
        ...
        Call Trace:
        perf_output_sample_regs+0x6c/0xd0
        perf_output_sample+0x4e4/0x830
        perf_event_output_forward+0x64/0x90
        __perf_event_overflow+0x8c/0x1e0
        record_and_restart+0x220/0x5c0
        perf_event_interrupt+0x2d8/0x4d0
        performance_monitor_exception+0x54/0x70
        performance_monitor_common+0x158/0x160
        --- interrupt: f01 at avtab_search_node+0x150/0x1a0
            LR = avtab_search_node+0x100/0x1a0
        ...
        load_elf_binary+0x6e8/0x15a0
        search_binary_handler+0xe8/0x290
        do_execveat_common.isra.14+0x5f4/0x840
        call_usermodehelper_exec_async+0x170/0x210
        ret_from_kernel_thread+0x5c/0x7c
      
      Fix it by setting abi to PERF_SAMPLE_REGS_ABI_NONE when userspace
      pt_regs are not set.
      
      Fixes: ed4a4ef8 ("powerpc/perf: Add support for sampling interrupt register state")
      Signed-off-by: default avatarRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Acked-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b660fcb
    • Kees Cook's avatar
      fs/exec.c: account for argv/envp pointers · 3d6848e4
      Kees Cook authored
      commit 98da7d08 upstream.
      
      When limiting the argv/envp strings during exec to 1/4 of the stack limit,
      the storage of the pointers to the strings was not included.  This means
      that an exec with huge numbers of tiny strings could eat 1/4 of the stack
      limit in strings and then additional space would be later used by the
      pointers to the strings.
      
      For example, on 32-bit with a 8MB stack rlimit, an exec with 1677721
      single-byte strings would consume less than 2MB of stack, the max (8MB /
      4) amount allowed, but the pointers to the strings would consume the
      remaining additional stack space (1677721 * 4 == 6710884).
      
      The result (1677721 + 6710884 == 8388605) would exhaust stack space
      entirely.  Controlling this stack exhaustion could result in
      pathological behavior in setuid binaries (CVE-2017-1000365).
      
      [akpm@linux-foundation.org: additional commenting from Kees]
      Fixes: b6a2fea3 ("mm: variable length argument support")
      Link: http://lkml.kernel.org/r/20170622001720.GA32173@beastSigned-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Qualys Security Advisory <qsa@qualys.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d6848e4
    • Takashi Iwai's avatar
      ALSA: pcm: Don't treat NULL chmap as a fatal error · 552a14a5
      Takashi Iwai authored
      commit 2deaeaf1 upstream.
      
      The standard PCM chmap helper callbacks treat the NULL info->chmap as
      a fatal error and spews the kernel warning with stack trace when
      CONFIG_SND_DEBUG is on.  This was OK, originally it was supposed to be
      always static and non-NULL.  But, as the recent addition of Intel LPE
      audio driver shows, the chmap content may vary dynamically, and it can
      be even NULL when disconnected.  The user still sees the kernel
      warning unnecessarily.
      
      For clearing such a confusion, this patch simply removes the
      snd_BUG_ON() in each place, just returns an error without warning.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      552a14a5
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: Fix stall of process context at packet error · 8c9c55a0
      Takashi Sakamoto authored
      commit 4a9bfafc upstream.
      
      At Linux v3.5, packet processing can be done in process context of ALSA
      PCM application as well as software IRQ context for OHCI 1394. Below is
      an example of the callgraph (some calls are omitted).
      
      ioctl(2) with e.g. HWSYNC
      (sound/core/pcm_native.c)
      ->snd_pcm_common_ioctl1()
        ->snd_pcm_hwsync()
          ->snd_pcm_stream_lock_irq
          (sound/core/pcm_lib.c)
          ->snd_pcm_update_hw_ptr()
            ->snd_pcm_udpate_hw_ptr0()
              ->struct snd_pcm_ops.pointer()
              (sound/firewire/*)
              = Each handler on drivers in ALSA firewire stack
                (sound/firewire/amdtp-stream.c)
                ->amdtp_stream_pcm_pointer()
                  (drivers/firewire/core-iso.c)
                  ->fw_iso_context_flush_completions()
                    ->struct fw_card_driver.flush_iso_completion()
                    (drivers/firewire/ohci.c)
                    = flush_iso_completions()
                      ->struct fw_iso_context.callback.sc
                      (sound/firewire/amdtp-stream.c)
                      = in_stream_callback() or out_stream_callback()
                        ->...
          ->snd_pcm_stream_unlock_irq
      
      When packet queueing error occurs or detecting invalid packets in
      'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
      is called on local CPU with disabled IRQ.
      
      (sound/firewire/amdtp-stream.c)
      in_stream_callback() or out_stream_callback()
      ->amdtp_stream_pcm_abort()
        ->snd_pcm_stop_xrun()
          ->snd_pcm_stream_lock_irqsave()
          ->snd_pcm_stop()
          ->snd_pcm_stream_unlock_irqrestore()
      
      The process is stalled on the CPU due to attempt to acquire recursive lock.
      
      [  562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
      [  562.630861]      2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
      [  562.630862]      (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
      [  562.630866] Task dump for CPU 2:
      [  562.630867] alsa-source-OXF R  running task        0  6619      1 0x00000008
      [  562.630870] Call Trace:
      [  562.630876]  ? vt_console_print+0x79/0x3e0
      [  562.630880]  ? msg_print_text+0x9d/0x100
      [  562.630883]  ? up+0x32/0x50
      [  562.630885]  ? irq_work_queue+0x8d/0xa0
      [  562.630886]  ? console_unlock+0x2b6/0x4b0
      [  562.630888]  ? vprintk_emit+0x312/0x4a0
      [  562.630892]  ? dev_vprintk_emit+0xbf/0x230
      [  562.630895]  ? do_sys_poll+0x37a/0x550
      [  562.630897]  ? dev_printk_emit+0x4e/0x70
      [  562.630900]  ? __dev_printk+0x3c/0x80
      [  562.630903]  ? _raw_spin_lock+0x20/0x30
      [  562.630909]  ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
      [  562.630914]  ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
      [  562.630918]  ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
      [  562.630922]  ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
      [  562.630925]  ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
      [  562.630928]  ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
      [  562.630932]  ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
      [  562.630935]  ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
      [  562.630938]  ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
      [  562.630943]  ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
      [  562.630945]  ? poll_select_copy_remaining+0x150/0x150
      [  562.630947]  ? poll_select_copy_remaining+0x150/0x150
      [  562.630952]  ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
      [  562.630956]  ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
      [  562.630960]  ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
      [  562.630962]  ? futex_wake+0x90/0x170
      [  562.630966]  ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
      [  562.630970]  ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
      [  562.630972]  ? do_vfs_ioctl+0xa3/0x610
      [  562.630974]  ? vfs_read+0x11b/0x130
      [  562.630976]  ? SyS_ioctl+0x79/0x90
      [  562.630978]  ? entry_SYSCALL_64_fastpath+0x1e/0xad
      
      This commit fixes the above bug. This assumes two cases:
      1. Any error is detected in software IRQ context of OHCI 1394 context.
      In this case, PCM substream should be aborted in packet handler. On the
      other hand, it should not be done in any process context. TO distinguish
      these two context, use 'in_interrupt()' macro.
      2. Any error is detect in process context of ALSA PCM application.
      In this case, PCM substream should not be aborted in packet handler
      because PCM substream lock is acquired. The task to abort PCM substream
      should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
      returned at 'struct snd_pcm_ops.pointer()'.
      Suggested-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Fixes: e9148ddd("ALSA: firewire-lib: flush completed packets when reading PCM position")
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c9c55a0
    • Jan Beulich's avatar
      xen-blkback: don't leak stack data via response ring · 4ae2cb91
      Jan Beulich authored
      commit 089bc014 upstream.
      
      Rather than constructing a local structure instance on the stack, fill
      the fields directly on the shared ring, just like other backends do.
      Build on the fact that all response structure flavors are actually
      identical (the old code did make this assumption too).
      
      This is XSA-216.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4ae2cb91
    • Juergen Gross's avatar
      xen/blkback: fix disconnect while I/Os in flight · e5c49c17
      Juergen Gross authored
      commit 46464411 upstream.
      
      Today disconnecting xen-blkback is broken in case there are still
      I/Os in flight: xen_blkif_disconnect() will bail out early without
      releasing all resources in the hope it will be called again when
      the last request has terminated. This, however, won't happen as
      xen_blkif_free() won't be called on termination of the last running
      request: xen_blkif_put() won't decrement the blkif refcnt to 0 as
      xen_blkif_disconnect() didn't finish before thus some xen_blkif_put()
      calls in xen_blkif_disconnect() didn't happen.
      
      To solve this deadlock xen_blkif_disconnect() and
      xen_blkif_alloc_rings() shouldn't use xen_blkif_put() and
      xen_blkif_get() but use some other way to do their accounting of
      resources.
      
      This at once fixes another error in xen_blkif_disconnect(): when it
      returned early with -EBUSY for another ring than 0 it would call
      xen_blkif_put() again for already handled rings on a subsequent call.
      This will lead to inconsistencies in the refcnt handling.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Tested-by: default avatarSteven Haigh <netwiz@crc.id.au>
      Acked-by: default avatarRoger Pau Monné <roger.pau@citrix.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e5c49c17
    • Chen-Yu Tsai's avatar
      clk: sunxi-ng: a31: Correct lcd1-ch1 clock register offset · 0e051f17
      Chen-Yu Tsai authored
      commit 38b8f823 upstream.
      
      The register offset for the lcd1-ch1 clock was incorrectly pointing to
      the lcd0-ch1 clock. This resulted in the lcd0-ch1 clock being disabled
      when the clk core disables unused clocks. This then stops the simplefb
      HDMI output path.
      Reported-by: default avatarBob Ham <rah@settrans.net>
      Fixes: c6e6c96d ("clk: sunxi-ng: Add A31/A31s clocks")
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0e051f17
  2. 24 Jun, 2017 25 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.34 · 493ecd5c
      Greg Kroah-Hartman authored
      493ecd5c
    • Hugh Dickins's avatar
      mm: fix new crash in unmapped_area_topdown() · ce7fe859
      Hugh Dickins authored
      commit f4cb767d upstream.
      
      Trinity gets kernel BUG at mm/mmap.c:1963! in about 3 minutes of
      mmap testing.  That's the VM_BUG_ON(gap_end < gap_start) at the
      end of unmapped_area_topdown().  Linus points out how MAP_FIXED
      (which does not have to respect our stack guard gap intentions)
      could result in gap_end below gap_start there.  Fix that, and
      the similar case in its alternative, unmapped_area().
      
      Fixes: 1be7107f ("mm: larger stack guard gap, between vmas")
      Reported-by: default avatarDave Jones <davej@codemonkey.org.uk>
      Debugged-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce7fe859
    • Helge Deller's avatar
      Allow stack to grow up to address space limit · 5d10ad62
      Helge Deller authored
      commit bd726c90 upstream.
      
      Fix expand_upwards() on architectures with an upward-growing stack (parisc,
      metag and partly IA-64) to allow the stack to reliably grow exactly up to
      the address space limit given by TASK_SIZE.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Acked-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5d10ad62
    • Hugh Dickins's avatar
      mm: larger stack guard gap, between vmas · cfc0eb40
      Hugh Dickins authored
      commit 1be7107f upstream.
      
      Stack guard page is a useful feature to reduce a risk of stack smashing
      into a different mapping. We have been using a single page gap which
      is sufficient to prevent having stack adjacent to a different mapping.
      But this seems to be insufficient in the light of the stack usage in
      userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
      used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
      which is 256kB or stack strings with MAX_ARG_STRLEN.
      
      This will become especially dangerous for suid binaries and the default
      no limit for the stack size limit because those applications can be
      tricked to consume a large portion of the stack and a single glibc call
      could jump over the guard page. These attacks are not theoretical,
      unfortunatelly.
      
      Make those attacks less probable by increasing the stack guard gap
      to 1MB (on systems with 4k pages; but make it depend on the page size
      because systems with larger base pages might cap stack allocations in
      the PAGE_SIZE units) which should cover larger alloca() and VLA stack
      allocations. It is obviously not a full fix because the problem is
      somehow inherent, but it should reduce attack space a lot.
      
      One could argue that the gap size should be configurable from userspace,
      but that can be done later when somebody finds that the new 1MB is wrong
      for some special case applications.  For now, add a kernel command line
      option (stack_guard_gap) to specify the stack gap size (in page units).
      
      Implementation wise, first delete all the old code for stack guard page:
      because although we could get away with accounting one extra page in a
      stack vma, accounting a larger gap can break userspace - case in point,
      a program run with "ulimit -S -v 20000" failed when the 1MB gap was
      counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
      and strict non-overcommit mode.
      
      Instead of keeping gap inside the stack vma, maintain the stack guard
      gap as a gap between vmas: using vm_start_gap() in place of vm_start
      (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
      places which need to respect the gap - mainly arch_get_unmapped_area(),
      and and the vma tree's subtree_gap support for that.
      Original-patch-by: default avatarOleg Nesterov <oleg@redhat.com>
      Original-patch-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Tested-by: Helge Deller <deller@gmx.de> # parisc
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      [wt: backport to 4.11: adjust context]
      [wt: backport to 4.9: adjust context ; kernel doc was not in admin-guide]
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cfc0eb40
    • Thomas Gleixner's avatar
      alarmtimer: Rate limit periodic intervals · 04651048
      Thomas Gleixner authored
      commit ff86bf0c upstream.
      
      The alarmtimer code has another source of potentially rearming itself too
      fast. Interval timers with a very samll interval have a similar CPU hog
      effect as the previously fixed overflow issue.
      
      The reason is that alarmtimers do not implement the normal protection
      against this kind of problem which the other posix timer use:
      
        timer expires -> queue signal -> deliver signal -> rearm timer
      
      This scheme brings the rearming under scheduler control and prevents
      permanently firing timers which hog the CPU.
      
      Bringing this scheme to the alarm timer code is a major overhaul because it
      lacks all the necessary mechanisms completely.
      
      So for a quick fix limit the interval to one jiffie. This is not
      problematic in practice as alarmtimers are usually backed by an RTC for
      suspend which have 1 second resolution. It could be therefor argued that
      the resolution of this clock should be set to 1 second in general, but
      that's outside the scope of this fix.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: syzkaller <syzkaller@googlegroups.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Link: http://lkml.kernel.org/r/20170530211655.896767100@linutronix.deSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      04651048
    • David Miller's avatar
      crypto: Work around deallocated stack frame reference gcc bug on sparc. · b355b899
      David Miller authored
      commit d41519a6 upstream.
      
      On sparc, if we have an alloca() like situation, as is the case with
      SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack
      memory.  The result can be that the value is clobbered if a trap
      or interrupt arrives at just the right instruction.
      
      It only occurs if the function ends returning a value from that
      alloca() area and that value can be placed into the return value
      register using a single instruction.
      
      For example, in lib/libcrc32c.c:crc32c() we end up with a return
      sequence like:
      
              return  %i7+8
               lduw   [%o5+16], %o0   ! MEM[(u32 *)__shash_desc.1_10 + 16B],
      
      %o5 holds the base of the on-stack area allocated for the shash
      descriptor.  But the return released the stack frame and the
      register window.
      
      So if an intererupt arrives between 'return' and 'lduw', then
      the value read at %o5+16 can be corrupted.
      
      Add a data compiler barrier to work around this problem.  This is
      exactly what the gcc fix will end up doing as well, and it absolutely
      should not change the code generated for other cpus (unless gcc
      on them has the same bug :-)
      
      With crucial insight from Eric Sandeen.
      Reported-by: default avatarAnatoly Pugachev <matorola@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      b355b899
    • Hon Ching \(Vicky) Lo's avatar
      vTPM: Fix missing NULL check · 7dfe7ca9
      Hon Ching \(Vicky) Lo authored
      commit 31574d32 upstream.
      
      The current code passes the address of tpm_chip as the argument to
      dev_get_drvdata() without prior NULL check in
      tpm_ibmvtpm_get_desired_dma.  This resulted an oops during kernel
      boot when vTPM is enabled in Power partition configured in active
      memory sharing mode.
      
      The vio_driver's get_desired_dma() is called before the probe(), which
      for vtpm is tpm_ibmvtpm_probe, and it's this latter function that
      initializes the driver and set data.  Attempting to get data before
      the probe() caused the problem.
      
      This patch adds a NULL check to the tpm_ibmvtpm_get_desired_dma.
      
      fixes: 9e0d39d8 ("tpm: Remove useless priv field in struct tpm_vendor_specific")
      Signed-off-by: default avatarHon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com>
      Reviewed-by: default avatarJarkko Sakkine <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      7dfe7ca9
    • Paul Burton's avatar
      MIPS: .its targets depend on vmlinux · ecae4733
      Paul Burton authored
      commit bcd7c45e upstream.
      
      The .its targets require information about the kernel binary, such as
      its entry point, which is extracted from the vmlinux ELF. We therefore
      require that the ELF is built before the .its files are generated.
      Declare this requirement in the Makefile such that make will ensure this
      is always the case, otherwise in corner cases we can hit issues as the
      .its is generated with an incorrect (either invalid or stale) entry
      point.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Fixes: cf2a5e0b ("MIPS: Support generating Flattened Image Trees (.itb)")
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16179/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ecae4733
    • Paul Burton's avatar
      MIPS: Fix bnezc/jialc return address calculation · 6b706cbb
      Paul Burton authored
      commit 1a73d931 upstream.
      
      The code handling the pop76 opcode (ie. bnezc & jialc instructions) in
      __compute_return_epc_for_insn() needs to set the value of $31 in the
      jialc case, which is encoded with rs = 0. However its check to
      differentiate bnezc (rs != 0) from jialc (rs = 0) was unfortunately
      backwards, meaning that if we emulate a bnezc instruction we clobber $31
      & if we emulate a jialc instruction it actually behaves like a jic
      instruction.
      
      Fix this by inverting the check of rs to match the way the instructions
      are actually encoded.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Fixes: 28d6f93d ("MIPS: Emulate the new MIPS R6 BNEZC and JIALC instructions")
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16178/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6b706cbb
    • Shuah Khan's avatar
      usb: dwc3: exynos fix axius clock error path to do cleanup · 22921a9e
      Shuah Khan authored
      commit 8ae584d1 upstream.
      
      Axius clock error path returns without disabling clock and suspend clock.
      Fix it to disable them before returning error.
      Reviewed-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22921a9e
    • Christophe JAILLET's avatar
      usb: gadget: composite: Fix function used to free memory · f0ee203c
      Christophe JAILLET authored
      commit 990758c5 upstream.
      
      'cdev->os_desc_req' has been allocated with 'usb_ep_alloc_request()' so
      'usb_ep_free_request()' should be used to free it.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0ee203c
    • Thomas Gleixner's avatar
      alarmtimer: Prevent overflow of relative timers · 8ee7f06f
      Thomas Gleixner authored
      commit f4781e76 upstream.
      
      Andrey reported a alartimer related RCU stall while fuzzing the kernel with
      syzkaller.
      
      The reason for this is an overflow in ktime_add() which brings the
      resulting time into negative space and causes immediate expiry of the
      timer. The following rearm with a small interval does not bring the timer
      back into positive space due to the same issue.
      
      This results in a permanent firing alarmtimer which hogs the CPU.
      
      Use ktime_add_safe() instead which detects the overflow and clamps the
      result to KTIME_SEC_MAX.
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: syzkaller <syzkaller@googlegroups.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Link: http://lkml.kernel.org/r/20170530211655.802921648@linutronix.deSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ee7f06f
    • Heiner Kallweit's avatar
      genirq: Release resources in __setup_irq() error path · 76628325
      Heiner Kallweit authored
      commit fa07ab72 upstream.
      
      In case __irq_set_trigger() fails the resources requested via
      irq_request_resources() are not released.
      
      Add the missing release call into the error handling path.
      
      Fixes: c1bacbae ("genirq: Provide irq_request/release_resources chip callbacks")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/655538f5-cb20-a892-ff15-fbd2dd1fa4ec@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      76628325
    • Andy Lutomirski's avatar
      sched/core: Idle_task_exit() shouldn't use switch_mm_irqs_off() · 8a48b7ea
      Andy Lutomirski authored
      commit 252d2a41 upstream.
      
      idle_task_exit() can be called with IRQs on x86 on and therefore
      should use switch_mm(), not switch_mm_irqs_off().
      
      This doesn't seem to cause any problems right now, but it will
      confuse my upcoming TLB flush changes.  Nonetheless, I think it
      should be backported because it's trivial.  There won't be any
      meaningful performance impact because idle_task_exit() is only
      used when offlining a CPU.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: f98db601 ("sched/core: Add switch_mm_irqs_off() and use it in the scheduler")
      Link: http://lkml.kernel.org/r/ca3d1a9fa93a0b49f5a8ff729eda3640fb6abdf9.1497034141.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a48b7ea
    • Jean-Baptiste Maneyrol's avatar
      iio: imu: inv_mpu6050: add accel lpf setting for chip >= MPU6500 · cf6ac3ab
      Jean-Baptiste Maneyrol authored
      commit 948588e2 upstream.
      
      Starting from MPU6500, accelerometer dlpf is set in a separate
      register named ACCEL_CONFIG_2.
      Add this new register in the map and set it for the corresponding
      chips.
      Signed-off-by: default avatarJean-Baptiste Maneyrol <jmaneyrol@invensense.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf6ac3ab
    • Yu Zhao's avatar
      swap: cond_resched in swap_cgroup_prepare() · f7ae7d22
      Yu Zhao authored
      commit ef707629 upstream.
      
      I saw need_resched() warnings when swapping on large swapfile (TBs)
      because continuously allocating many pages in swap_cgroup_prepare() took
      too long.
      
      We already cond_resched when freeing page in swap_cgroup_swapoff().  Do
      the same for the page allocation.
      
      Link: http://lkml.kernel.org/r/20170604200109.17606-1-yuzhao@google.comSigned-off-by: default avatarYu Zhao <yuzhao@google.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarVladimir Davydov <vdavydov.dev@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7ae7d22
    • James Morse's avatar
      mm/memory-failure.c: use compound_head() flags for huge pages · 1419b875
      James Morse authored
      commit 7258ae5c upstream.
      
      memory_failure() chooses a recovery action function based on the page
      flags.  For huge pages it uses the tail page flags which don't have
      anything interesting set, resulting in:
      
      > Memory failure: 0x9be3b4: Unknown page state
      > Memory failure: 0x9be3b4: recovery action for unknown page: Failed
      
      Instead, save a copy of the head page's flags if this is a huge page,
      this means if there are no relevant flags for this tail page, we use the
      head pages flags instead.  This results in the me_huge_page() recovery
      action being called:
      
      > Memory failure: 0x9b7969: recovery action for huge page: Delayed
      
      For hugepages that have not yet been allocated, this allows the hugepage
      to be dequeued.
      
      Fixes: 524fca1e ("HWPOISON: fix misjudgement of page_action() for errors on mlocked pages")
      Link: http://lkml.kernel.org/r/20170524130204.21845-1-james.morse@arm.comSigned-off-by: default avatarJames Morse <james.morse@arm.com>
      Tested-by: default avatarPunit Agrawal <punit.agrawal@arm.com>
      Acked-by: default avatarPunit Agrawal <punit.agrawal@arm.com>
      Acked-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1419b875
    • Alan Stern's avatar
      USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks · 0c0d3d87
      Alan Stern authored
      commit f16443a0 upstream.
      
      Using the syzkaller kernel fuzzer, Andrey Konovalov generated the
      following error in gadgetfs:
      
      > BUG: KASAN: use-after-free in __lock_acquire+0x3069/0x3690
      > kernel/locking/lockdep.c:3246
      > Read of size 8 at addr ffff88003a2bdaf8 by task kworker/3:1/903
      >
      > CPU: 3 PID: 903 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #35
      > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      > Workqueue: usb_hub_wq hub_event
      > Call Trace:
      >  __dump_stack lib/dump_stack.c:16 [inline]
      >  dump_stack+0x292/0x395 lib/dump_stack.c:52
      >  print_address_description+0x78/0x280 mm/kasan/report.c:252
      >  kasan_report_error mm/kasan/report.c:351 [inline]
      >  kasan_report+0x230/0x340 mm/kasan/report.c:408
      >  __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:429
      >  __lock_acquire+0x3069/0x3690 kernel/locking/lockdep.c:3246
      >  lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
      >  __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
      >  _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151
      >  spin_lock include/linux/spinlock.h:299 [inline]
      >  gadgetfs_suspend+0x89/0x130 drivers/usb/gadget/legacy/inode.c:1682
      >  set_link_state+0x88e/0xae0 drivers/usb/gadget/udc/dummy_hcd.c:455
      >  dummy_hub_control+0xd7e/0x1fb0 drivers/usb/gadget/udc/dummy_hcd.c:2074
      >  rh_call_control drivers/usb/core/hcd.c:689 [inline]
      >  rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline]
      >  usb_hcd_submit_urb+0x92f/0x20b0 drivers/usb/core/hcd.c:1650
      >  usb_submit_urb+0x8b2/0x12c0 drivers/usb/core/urb.c:542
      >  usb_start_wait_urb+0x148/0x5b0 drivers/usb/core/message.c:56
      >  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
      >  usb_control_msg+0x341/0x4d0 drivers/usb/core/message.c:151
      >  usb_clear_port_feature+0x74/0xa0 drivers/usb/core/hub.c:412
      >  hub_port_disable+0x123/0x510 drivers/usb/core/hub.c:4177
      >  hub_port_init+0x1ed/0x2940 drivers/usb/core/hub.c:4648
      >  hub_port_connect drivers/usb/core/hub.c:4826 [inline]
      >  hub_port_connect_change drivers/usb/core/hub.c:4999 [inline]
      >  port_event drivers/usb/core/hub.c:5105 [inline]
      >  hub_event+0x1ae1/0x3d40 drivers/usb/core/hub.c:5185
      >  process_one_work+0xc08/0x1bd0 kernel/workqueue.c:2097
      >  process_scheduled_works kernel/workqueue.c:2157 [inline]
      >  worker_thread+0xb2b/0x1860 kernel/workqueue.c:2233
      >  kthread+0x363/0x440 kernel/kthread.c:231
      >  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:424
      >
      > Allocated by task 9958:
      >  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
      >  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
      >  set_track mm/kasan/kasan.c:525 [inline]
      >  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617
      >  kmem_cache_alloc_trace+0x87/0x280 mm/slub.c:2745
      >  kmalloc include/linux/slab.h:492 [inline]
      >  kzalloc include/linux/slab.h:665 [inline]
      >  dev_new drivers/usb/gadget/legacy/inode.c:170 [inline]
      >  gadgetfs_fill_super+0x24f/0x540 drivers/usb/gadget/legacy/inode.c:1993
      >  mount_single+0xf6/0x160 fs/super.c:1192
      >  gadgetfs_mount+0x31/0x40 drivers/usb/gadget/legacy/inode.c:2019
      >  mount_fs+0x9c/0x2d0 fs/super.c:1223
      >  vfs_kern_mount.part.25+0xcb/0x490 fs/namespace.c:976
      >  vfs_kern_mount fs/namespace.c:2509 [inline]
      >  do_new_mount fs/namespace.c:2512 [inline]
      >  do_mount+0x41b/0x2d90 fs/namespace.c:2834
      >  SYSC_mount fs/namespace.c:3050 [inline]
      >  SyS_mount+0xb0/0x120 fs/namespace.c:3027
      >  entry_SYSCALL_64_fastpath+0x1f/0xbe
      >
      > Freed by task 9960:
      >  save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
      >  save_stack+0x43/0xd0 mm/kasan/kasan.c:513
      >  set_track mm/kasan/kasan.c:525 [inline]
      >  kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590
      >  slab_free_hook mm/slub.c:1357 [inline]
      >  slab_free_freelist_hook mm/slub.c:1379 [inline]
      >  slab_free mm/slub.c:2961 [inline]
      >  kfree+0xed/0x2b0 mm/slub.c:3882
      >  put_dev+0x124/0x160 drivers/usb/gadget/legacy/inode.c:163
      >  gadgetfs_kill_sb+0x33/0x60 drivers/usb/gadget/legacy/inode.c:2027
      >  deactivate_locked_super+0x8d/0xd0 fs/super.c:309
      >  deactivate_super+0x21e/0x310 fs/super.c:340
      >  cleanup_mnt+0xb7/0x150 fs/namespace.c:1112
      >  __cleanup_mnt+0x1b/0x20 fs/namespace.c:1119
      >  task_work_run+0x1a0/0x280 kernel/task_work.c:116
      >  exit_task_work include/linux/task_work.h:21 [inline]
      >  do_exit+0x18a8/0x2820 kernel/exit.c:878
      >  do_group_exit+0x14e/0x420 kernel/exit.c:982
      >  get_signal+0x784/0x1780 kernel/signal.c:2318
      >  do_signal+0xd7/0x2130 arch/x86/kernel/signal.c:808
      >  exit_to_usermode_loop+0x1ac/0x240 arch/x86/entry/common.c:157
      >  prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
      >  syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
      >  entry_SYSCALL_64_fastpath+0xbc/0xbe
      >
      > The buggy address belongs to the object at ffff88003a2bdae0
      >  which belongs to the cache kmalloc-1024 of size 1024
      > The buggy address is located 24 bytes inside of
      >  1024-byte region [ffff88003a2bdae0, ffff88003a2bdee0)
      > The buggy address belongs to the page:
      > page:ffffea0000e8ae00 count:1 mapcount:0 mapping:          (null)
      > index:0x0 compound_mapcount: 0
      > flags: 0x100000000008100(slab|head)
      > raw: 0100000000008100 0000000000000000 0000000000000000 0000000100170017
      > raw: ffffea0000ed3020 ffffea0000f5f820 ffff88003e80efc0 0000000000000000
      > page dumped because: kasan: bad access detected
      >
      > Memory state around the buggy address:
      >  ffff88003a2bd980: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >  ffff88003a2bda00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      > >ffff88003a2bda80: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb
      >                                                                 ^
      >  ffff88003a2bdb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >  ffff88003a2bdb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      > ==================================================================
      
      What this means is that the gadgetfs_suspend() routine was trying to
      access dev->lock after it had been deallocated.  The root cause is a
      race in the dummy_hcd driver; the dummy_udc_stop() routine can race
      with the rest of the driver because it contains no locking.  And even
      when proper locking is added, it can still race with the
      set_link_state() function because that function incorrectly drops the
      private spinlock before invoking any gadget driver callbacks.
      
      The result of this race, as seen above, is that set_link_state() can
      invoke a callback in gadgetfs even after gadgetfs has been unbound
      from dummy_hcd's UDC and its private data structures have been
      deallocated.
      
      include/linux/usb/gadget.h documents that the ->reset, ->disconnect,
      ->suspend, and ->resume callbacks may be invoked in interrupt context.
      In general this is necessary, to prevent races with gadget driver
      removal.  This patch fixes dummy_hcd to retain the spinlock across
      these calls, and it adds a spinlock acquisition to dummy_udc_stop() to
      prevent the race.
      
      The net2280 driver makes the same mistake of dropping the private
      spinlock for its ->disconnect and ->reset callback invocations.  The
      patch fixes it too.
      
      Lastly, since gadgetfs_suspend() may be invoked in interrupt context,
      it cannot assume that interrupts are enabled when it runs.  It must
      use spin_lock_irqsave() instead of spin_lock_irq().  The patch fixes
      that bug as well.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c0d3d87
    • Alan Stern's avatar
      USB: gadget: fix GPF in gadgetfs · 3ff5f4f6
      Alan Stern authored
      commit f50b878f upstream.
      
      A NULL-pointer dereference bug in gadgetfs was uncovered by syzkaller:
      
      > kasan: GPF could be caused by NULL-ptr deref or user memory access
      > general protection fault: 0000 [#1] SMP KASAN
      > Dumping ftrace buffer:
      >    (ftrace buffer empty)
      > Modules linked in:
      > CPU: 2 PID: 4820 Comm: syz-executor0 Not tainted 4.12.0-rc4+ #5
      > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      > task: ffff880039542dc0 task.stack: ffff88003bdd0000
      > RIP: 0010:__list_del_entry_valid+0x7e/0x170 lib/list_debug.c:51
      > RSP: 0018:ffff88003bdd6e50 EFLAGS: 00010246
      > RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000010000
      > RDX: 0000000000000000 RSI: ffffffff86504948 RDI: ffffffff86504950
      > RBP: ffff88003bdd6e68 R08: ffff880039542dc0 R09: ffffffff8778ce00
      > R10: ffff88003bdd6e68 R11: dffffc0000000000 R12: 0000000000000000
      > R13: dffffc0000000000 R14: 1ffff100077badd2 R15: ffffffff864d2e40
      > FS:  0000000000000000(0000) GS:ffff88006dc00000(0000) knlGS:0000000000000000
      > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > CR2: 000000002014aff9 CR3: 0000000006022000 CR4: 00000000000006e0
      > Call Trace:
      >  __list_del_entry include/linux/list.h:116 [inline]
      >  list_del include/linux/list.h:124 [inline]
      >  usb_gadget_unregister_driver+0x166/0x4c0 drivers/usb/gadget/udc/core.c:1387
      >  dev_release+0x80/0x160 drivers/usb/gadget/legacy/inode.c:1187
      >  __fput+0x332/0x7f0 fs/file_table.c:209
      >  ____fput+0x15/0x20 fs/file_table.c:245
      >  task_work_run+0x19b/0x270 kernel/task_work.c:116
      >  exit_task_work include/linux/task_work.h:21 [inline]
      >  do_exit+0x18a3/0x2820 kernel/exit.c:878
      >  do_group_exit+0x149/0x420 kernel/exit.c:982
      >  get_signal+0x77f/0x1780 kernel/signal.c:2318
      >  do_signal+0xd2/0x2130 arch/x86/kernel/signal.c:808
      >  exit_to_usermode_loop+0x1a7/0x240 arch/x86/entry/common.c:157
      >  prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
      >  syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263
      >  entry_SYSCALL_64_fastpath+0xbc/0xbe
      > RIP: 0033:0x4461f9
      > RSP: 002b:00007fdac2b1ecf8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
      > RAX: fffffffffffffe00 RBX: 00000000007080c8 RCX: 00000000004461f9
      > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000007080c8
      > RBP: 00000000007080a8 R08: 0000000000000000 R09: 0000000000000000
      > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      > R13: 0000000000000000 R14: 00007fdac2b1f9c0 R15: 00007fdac2b1f700
      > Code: 00 00 00 00 ad de 49 39 c4 74 6a 48 b8 00 02 00 00 00 00 ad de
      > 48 89 da 48 39 c3 74 74 48 c1 ea 03 48 b8 00 00 00 00 00 fc ff df <80>
      > 3c 02 00 0f 85 92 00 00 00 48 8b 13 48 39 f2 75 66 49 8d 7c
      > RIP: __list_del_entry_valid+0x7e/0x170 lib/list_debug.c:51 RSP: ffff88003bdd6e50
      > ---[ end trace 30e94b1eec4831c8 ]---
      > Kernel panic - not syncing: Fatal exception
      
      The bug was caused by dev_release() failing to turn off its
      gadget_registered flag after unregistering the gadget driver.  As a
      result, when a later user closed the device file before writing a
      valid set of descriptors, dev_release() thought the gadget had been
      registered and tried to unregister it, even though it had not been.
      This led to the NULL pointer dereference.
      
      The fix is simple: turn off the flag when the gadget is unregistered.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ff5f4f6
    • Corentin Labbe's avatar
      usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk · 06178662
      Corentin Labbe authored
      commit d2f48f05 upstream.
      
      When plugging an USB webcam I see the following message:
      [106385.615559] xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?
      [106390.583860] handle_tx_event: 913 callbacks suppressed
      
      With this patch applied, I get no more printing of this message.
      Signed-off-by: default avatarCorentin Labbe <clabbe.montjoie@gmail.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06178662
    • YD Tseng's avatar
      usb: xhci: Fix USB 3.1 supported protocol parsing · 4581d7dd
      YD Tseng authored
      commit b72eb843 upstream.
      
      xHCI host controllers can have both USB 3.1 and 3.0 extended speed
      protocol lists. If the USB3.1 speed is parsed first and 3.0 second then
      the minor revision supported will be overwritten by the 3.0 speeds and
      the USB3 roothub will only show support for USB 3.0 speeds.
      
      This was the case with a xhci controller with the supported protocol
      capability listed below.
      In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
      is set as 0x10.  And then USB 3.0 is parsed.  However, the min_rev of
      usb3_rhub will be changed to 0x00. If USB 3.1 device is connected behind
      this host controller, the speed of USB 3.1 device just reports 5G speed
      using lsusb.
      
           00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
        00 01 08 00 00 00 00 00 40 00 00 00 00 00 00 00 00
        10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        20 02 08 10 03 55 53 42 20 01 02 00 00 00 00 00 00     //USB 3.1
        30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        40 02 08 00 03 55 53 42 20 03 06 00 00 00 00 00 00     //USB 3.0
        50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        60 02 08 00 02 55 53 42 20 09 0E 19 00 00 00 00 00     //USB 2.0
        70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      This patch fixes the issue by only owerwriting the minor revision if
      it is higher than the existing one.
      
      [reword commit message -Mathias]
      Signed-off-by: default avatarYD Tseng <yd_tseng@asmedia.com.tw>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4581d7dd
    • Dan Carpenter's avatar
      drivers/misc/c2port/c2port-duramar2150.c: checking for NULL instead of IS_ERR() · 2abac408
      Dan Carpenter authored
      commit 8128a31e upstream.
      
      c2port_device_register() never returns NULL, it uses error pointers.
      
      Link: http://lkml.kernel.org/r/20170412083321.GC3250@mwanda
      Fixes: 65131cd5 ("c2port: add c2port support for Eurotech Duramar 2150")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarRodolfo Giometti <giometti@linux.it>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2abac408
    • Dan Carpenter's avatar
      misc: mic: double free on ioctl error path · f28ba80c
      Dan Carpenter authored
      commit 816c9311 upstream.
      
      This function only has one caller.  Freeing "vdev" here leads to a use
      after free bug.  There are several other error paths in this function
      but this is the only one which frees "vdev".  It looks like the kfree()
      can be safely removed.
      
      Fixes: 61e9c905 ("misc: mic: Enable VOP host side functionality")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f28ba80c
    • Kalle Valo's avatar
      ath10k: fix napi crash during rmmod when probe firmware fails · 02d009e8
      Kalle Valo authored
      commit 1427228d upstream.
      
      This fixes the below crash when ath10k probe firmware fails, NAPI polling tries
      to access a rx ring resource which was never allocated. An easy way to
      reproduce this is easy to remove all the firmware files, load ath10k modules
      and ath10k will crash when calling 'rmmod ath10k_pci'. The fix is to call
      napi_enable() from ath10k_pci_hif_start() so that it matches with
      napi_disable() being called from ath10k_pci_hif_stop().
      
      Big thanks to Mohammed Shafi Shajakhan who debugged this and provided first
      version of the fix. In this patch I just fix the actual problem in pci.c
      instead of having a workaround in core.c.
      
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP:  __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
      __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
      
      Call Trace:
      
      [<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
      [ath10k_core]
      [<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0
      [ath10k_core]
      [<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80
      [<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150
      [<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
      [<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
      [<ffffffff817863af>] net_rx_action+0x20f/0x370
      Reported-by: default avatarBen Greear <greearb@candelatech.com>
      Fixes: 3c97f5de ("ath10k: implement NAPI support")
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02d009e8
    • Chris Brandt's avatar
      usb: r8a66597-hcd: decrease timeout · 07612c12
      Chris Brandt authored
      commit dd14a3e9 upstream.
      
      The timeout for BULK packets was 300ms which is a long time if other
      endpoints or devices are waiting for their turn. Changing it to 50ms
      greatly increased the overall performance for multi-endpoint devices.
      
      Fixes: 5d304358 ("usb: r8a66597-hcd: host controller driver for R8A6659")
      Signed-off-by: default avatarChris Brandt <chris.brandt@renesas.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07612c12