1. 29 Jun, 2017 22 commits
    • William Wu's avatar
      usb: gadget: f_fs: avoid out of bounds access on comp_desc · 889caad4
      William Wu authored
      commit b7f73850 upstream.
      
      Companion descriptor is only used for SuperSpeed endpoints,
      if the endpoints are HighSpeed or FullSpeed, the Companion
      descriptor will not allocated, so we can only access it if
      gadget is SuperSpeed.
      
      I can reproduce this issue on Rockchip platform rk3368 SoC
      which supports USB 2.0, and use functionfs for ADB. Kernel
      build with CONFIG_KASAN=y and CONFIG_SLUB_DEBUG=y report
      the following BUG:
      
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in ffs_func_set_alt+0x224/0x3a0 at addr ffffffc0601f6509
      Read of size 1 by task swapper/0/0
      ============================================================================
      BUG kmalloc-256 (Not tainted): kasan: bad access detected
      ----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in ffs_func_bind+0x52c/0x99c age=1275 cpu=0 pid=1
      alloc_debug_processing+0x128/0x17c
      ___slab_alloc.constprop.58+0x50c/0x610
      __slab_alloc.isra.55.constprop.57+0x24/0x34
      __kmalloc+0xe0/0x250
      ffs_func_bind+0x52c/0x99c
      usb_add_function+0xd8/0x1d4
      configfs_composite_bind+0x48c/0x570
      udc_bind_to_driver+0x6c/0x170
      usb_udc_attach_driver+0xa4/0xd0
      gadget_dev_desc_UDC_store+0xcc/0x118
      configfs_write_file+0x1a0/0x1f8
      __vfs_write+0x64/0x174
      vfs_write+0xe4/0x200
      SyS_write+0x68/0xc8
      el0_svc_naked+0x24/0x28
      INFO: Freed in inode_doinit_with_dentry+0x3f0/0x7c4 age=1275 cpu=7 pid=247
      ...
      Call trace:
      [<ffffff900808aab4>] dump_backtrace+0x0/0x230
      [<ffffff900808acf8>] show_stack+0x14/0x1c
      [<ffffff90084ad420>] dump_stack+0xa0/0xc8
      [<ffffff90082157cc>] print_trailer+0x188/0x198
      [<ffffff9008215948>] object_err+0x3c/0x4c
      [<ffffff900821b5ac>] kasan_report+0x324/0x4dc
      [<ffffff900821aa38>] __asan_load1+0x24/0x50
      [<ffffff90089eb750>] ffs_func_set_alt+0x224/0x3a0
      [<ffffff90089d3760>] composite_setup+0xdcc/0x1ac8
      [<ffffff90089d7394>] android_setup+0x124/0x1a0
      [<ffffff90089acd18>] _setup+0x54/0x74
      [<ffffff90089b6b98>] handle_ep0+0x3288/0x4390
      [<ffffff90089b9b44>] dwc_otg_pcd_handle_out_ep_intr+0x14dc/0x2ae4
      [<ffffff90089be85c>] dwc_otg_pcd_handle_intr+0x1ec/0x298
      [<ffffff90089ad680>] dwc_otg_pcd_irq+0x10/0x20
      [<ffffff9008116328>] handle_irq_event_percpu+0x124/0x3ac
      [<ffffff9008116610>] handle_irq_event+0x60/0xa0
      [<ffffff900811af30>] handle_fasteoi_irq+0x10c/0x1d4
      [<ffffff9008115568>] generic_handle_irq+0x30/0x40
      [<ffffff90081159b4>] __handle_domain_irq+0xac/0xdc
      [<ffffff9008080e9c>] gic_handle_irq+0x64/0xa4
      ...
      Memory state around the buggy address:
        ffffffc0601f6400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        ffffffc0601f6480: 00 00 00 00 00 00 00 00 00 00 06 fc fc fc fc fc
       >ffffffc0601f6500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                             ^
        ffffffc0601f6580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffffffc0601f6600: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
      ==================================================================
      Signed-off-by: default avatarWilliam Wu <william.wu@rock-chips.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Cc: Jerry Zhang <zhangjerry@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      889caad4
    • Michael Ellerman's avatar
      powerpc/slb: Force a full SLB flush when we insert for a bad EA · db7130d6
      Michael Ellerman authored
      [Note this patch is not upstream. The bug fix was fixed differently in
      upstream prior to the bug being identified.]
      
      The SLB miss handler calls slb_allocate_realmode() in order to create an
      SLB entry for the faulting address. At the very start of that function
      we check that the faulting Effective Address (EA) is less than
      PGTABLE_RANGE (ignoring the region), ie. is it an address which could
      possibly fit in the virtual address space.
      
      For an EA which fails that test, we branch out of line (to label 8), but
      we still go on to create an SLB entry for the address. The SLB entry we
      create has a VSID of 0, which means it will never match anything in the
      hash table and so can't actually translate to a physical address.
      
      However that SLB entry will be inserted in the SLB, and so needs to be
      managed properly like any other SLB entry. In particular we need to
      insert the SLB entry in the SLB cache, so that it will be flushed when
      the process is descheduled.
      
      And that is where the bugs begin. The first bug is that slb_finish_load()
      uses cr7 to decide if it should insert the SLB entry into the SLB cache.
      When we come from the invalid EA case we don't set cr7, it just has some
      junk value from userspace. So we may or may not insert the SLB entry in
      the SLB cache. If we fail to insert it, we may then incorrectly leave it
      in the SLB when the process is descheduled.
      
      The second bug is that even if we do happen to add the entry to the SLB
      cache, we do not have enough bits in the SLB cache to remember the full
      ESID value for very large EAs.
      
      For example if a process branches to 0x788c545a18000000, that results in
      a 256MB SLB entry with an ESID of 0x788c545a1. But each entry in the SLB
      cache is only 32-bits, meaning we truncate the ESID to 0x88c545a1. This
      has the same effect as the first bug, we incorrectly leave the SLB entry
      in the SLB when the process is descheduled.
      
      When a process accesses an invalid EA it results in a SEGV signal being
      sent to the process, which typically results in the process being
      killed. Process death isn't instantaneous however, the process may catch
      the SEGV signal and continue somehow, or the kernel may start writing a
      core dump for the process, either of which means it's possible for the
      process to be preempted while its processing the SEGV but before it's
      been killed.
      
      If that happens, when the process is scheduled back onto the CPU we will
      allocate a new SLB entry for the NIP, which will insert a second entry
      into the SLB for the bad EA. Because we never flushed the original
      entry, due to either bug one or two, we now have two SLB entries that
      match the same EA.
      
      If another access is made to that EA, either by the process continuing
      after catching the SEGV, or by a second process accessing the same bad
      EA on the same CPU, we will trigger an SLB multi-hit machine check
      exception. This has been observed happening in the wild.
      
      The fix is when we hit the invalid EA case, we mark the SLB cache as
      being full. This causes us to not insert the truncated ESID into the SLB
      cache, and means when the process is switched out we will flush the
      entire SLB. Note that this works both for the original fault and for a
      subsequent call to slb_allocate_realmode() from switch_slb().
      
      Because we mark the SLB cache as full, it doesn't really matter what
      value is in cr7, but rather than leaving it as something random we set
      it to indicate the address was a kernel address. That also skips the
      attempt to insert it in the SLB cache which is a nice side effect.
      
      Another way to fix the bug would be to make the entries in the SLB cache
      wider, so that we don't truncate the ESID. However this would be a more
      intrusive change as it alters the size and layout of the paca.
      
      This bug was fixed in upstream by commit f0f558b1 ("powerpc/mm:
      Preserve CFAR value on SLB miss caused by access to bogus address"),
      which changed the way we handle a bad EA entirely removing this bug in
      the process.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db7130d6
    • Joël Esponde's avatar
      mtd: spi-nor: fix spansion quad enable · 8fcb215c
      Joël Esponde authored
      commit 807c1625 upstream.
      
      With the S25FL127S nor flash part, each writing to the configuration
      register takes hundreds of ms. During that  time, no more accesses to
      the flash should be done (even reads).
      
      This commit adds a wait loop after the register writing until the flash
      finishes its work.
      
      This issue could make rootfs mounting fail when the latter was done too
      much closely to this quad enable bit setting step. And in this case, a
      driver as UBIFS may try to recover the filesystem and may broke it
      completely.
      Signed-off-by: default avatarJoël Esponde <joel.esponde@honeywell.com>
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8fcb215c
    • Tobias Wolf's avatar
      of: Add check to of_scan_flat_dt() before accessing initial_boot_params · 7dfea167
      Tobias Wolf authored
      commit 3ec75441 upstream.
      
      An empty __dtb_start to __dtb_end section might result in
      initial_boot_params being null for arch/mips/ralink. This showed that the
      boot process hangs indefinitely in of_scan_flat_dt().
      Signed-off-by: default avatarTobias Wolf <dev-NTEO@vplace.de>
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14605/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7dfea167
    • David Howells's avatar
      rxrpc: Fix several cases where a padded len isn't checked in ticket decode · eab38dfd
      David Howells authored
      commit 5f2f9765 upstream.
      
      This fixes CVE-2017-7482.
      
      When a kerberos 5 ticket is being decoded so that it can be loaded into an
      rxrpc-type key, there are several places in which the length of a
      variable-length field is checked to make sure that it's not going to
      overrun the available data - but the data is padded to the nearest
      four-byte boundary and the code doesn't check for this extra.  This could
      lead to the size-remaining variable wrapping and the data pointer going
      over the end of the buffer.
      
      Fix this by making the various variable-length data checks use the padded
      length.
      Reported-by: default avatar石磊 <shilei-c@360.cn>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarMarc Dionne <marc.c.dionne@auristor.com>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eab38dfd
    • Johan Hovold's avatar
      USB: usbip: fix nonconforming hub descriptor · 800d7454
      Johan Hovold authored
      commit ec963b41 upstream.
      
      Fix up the root-hub descriptor to accommodate the variable-length
      DeviceRemovable and PortPwrCtrlMask fields, while marking all ports as
      removable (and leaving the reserved bit zero unset).
      
      Also add a build-time constraint on VHCI_HC_PORTS which must never be
      greater than USB_MAXCHILDREN (but this was only enforced through a
      KConfig constant).
      
      This specifically fixes the descriptor layout whenever VHCI_HC_PORTS is
      greater than seven (default is 8).
      
      Fixes: 04679b34 ("Staging: USB/IP: add client driver")
      Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
      Cc: Valentina Manea <valentina.manea.m@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarShuah Khan <shuahkh@osg.samsung.com>
      [ johan: backport to v4.4, which uses VHCI_NPORTS ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      800d7454
    • Alex Deucher's avatar
      drm/amdgpu: adjust default display clock · 525e496a
      Alex Deucher authored
      commit 52b482b0 upstream.
      
      Increase the default display clock on newer asics to
      accomodate some high res modes with really high refresh
      rates.
      
      bug: https://bugs.freedesktop.org/show_bug.cgi?id=93826Acked-by: default avatarChunming Zhou <david1.zhou@amd.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      525e496a
    • Alex Deucher's avatar
      drm/amdgpu/atom: fix ps allocation size for EnableDispPowerGating · 52652784
      Alex Deucher authored
      commit 05b4017b upstream.
      
      We were using the wrong structure which lead to an overflow
      on some boards.
      
      bug: https://bugs.freedesktop.org/show_bug.cgi?id=101387Acked-by: default avatarChunming Zhou <david1.zhou@amd.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52652784
    • Alex Deucher's avatar
    • Alex Deucher's avatar
    • Nicholas Bellinger's avatar
      iscsi-target: Reject immediate data underflow larger than SCSI transfer length · fe8003da
      Nicholas Bellinger authored
      commit abb85a9b upstream.
      
      When iscsi WRITE underflow occurs there are two different scenarios
      that can happen.
      
      Normally in practice, when an EDTL vs. SCSI CDB TRANSFER LENGTH
      underflow is detected, the iscsi immediate data payload is the
      smaller SCSI CDB TRANSFER LENGTH.
      
      That is, when a host fabric LLD is using a fixed size EDTL for
      a specific control CDB, the SCSI CDB TRANSFER LENGTH and actual
      SCSI payload ends up being smaller than EDTL.  In iscsi, this
      means the received iscsi immediate data payload matches the
      smaller SCSI CDB TRANSFER LENGTH, because there is no more
      SCSI payload to accept beyond SCSI CDB TRANSFER LENGTH.
      
      However, it's possible for a malicous host to send a WRITE
      underflow where EDTL is larger than SCSI CDB TRANSFER LENGTH,
      but incoming iscsi immediate data actually matches EDTL.
      
      In the wild, we've never had a iscsi host environment actually
      try to do this.
      
      For this special case, it's wrong to truncate part of the
      control CDB payload and continue to process the command during
      underflow when immediate data payload received was larger than
      SCSI CDB TRANSFER LENGTH, so go ahead and reject and drop the
      bogus payload as a defensive action.
      
      Note this potential bug was originally relaxed by the following
      for allowing WRITE underflow in MSFT FCP host environments:
      
         commit c72c5250
         Author: Roland Dreier <roland@purestorage.com>
         Date:   Wed Jul 22 15:08:18 2015 -0700
      
            target: allow underflow/overflow for PR OUT etc. commands
      
      Cc: Roland Dreier <roland@purestorage.com>
      Cc: Mike Christie <mchristi@redhat.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe8003da
    • Nicholas Bellinger's avatar
      target: Fix kref->refcount underflow in transport_cmd_finish_abort · d374be75
      Nicholas Bellinger authored
      commit 73d4e580 upstream.
      
      This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED
      when a fabric driver drops it's second reference from below the
      target_core_tmr.c based callers of transport_cmd_finish_abort().
      
      Recently with the conversion of kref to refcount_t, this bug was
      manifesting itself as:
      
      [705519.601034] refcount_t: underflow; use-after-free.
      [705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 20116.512 msecs
      [705539.719111] ------------[ cut here ]------------
      [705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184 refcount_sub_and_test+0x33/0x51
      
      Since the original kref atomic_t based kref_put() didn't check for
      underflow and only invoked the final callback when zero was reached,
      this bug did not manifest in practice since all se_cmd memory is
      using preallocated tags.
      
      To address this, go ahead and propigate the existing return from
      transport_put_cmd() up via transport_cmd_finish_abort(), and
      change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
      callers to only do their local target_put_sess_cmd() if necessary.
      Reported-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Tested-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Mike Christie <mchristi@redhat.com>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Tested-by: default avatarGary Guo <ghg@datera.io>
      Tested-by: default avatarChu Yuan Lin <cyl@datera.io>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d374be75
    • John Stultz's avatar
      time: Fix clock->read(clock) race around clocksource changes · 1fecf397
      John Stultz authored
      commit ceea5e37 upstream.
      
      In tests, which excercise switching of clocksources, a NULL
      pointer dereference can be observed on AMR64 platforms in the
      clocksource read() function:
      
      u64 clocksource_mmio_readl_down(struct clocksource *c)
      {
      	return ~(u64)readl_relaxed(to_mmio_clksrc(c)->reg) & c->mask;
      }
      
      This is called from the core timekeeping code via:
      
      	cycle_now = tkr->read(tkr->clock);
      
      tkr->read is the cached tkr->clock->read() function pointer.
      When the clocksource is changed then tkr->clock and tkr->read
      are updated sequentially. The code above results in a sequential
      load operation of tkr->read and tkr->clock as well.
      
      If the store to tkr->clock hits between the loads of tkr->read
      and tkr->clock, then the old read() function is called with the
      new clock pointer. As a consequence the read() function
      dereferences a different data structure and the resulting 'reg'
      pointer can point anywhere including NULL.
      
      This problem was introduced when the timekeeping code was
      switched over to use struct tk_read_base. Before that, it was
      theoretically possible as well when the compiler decided to
      reload clock in the code sequence:
      
           now = tk->clock->read(tk->clock);
      
      Add a helper function which avoids the issue by reading
      tk_read_base->clock once into a local variable clk and then issue
      the read function via clk->read(clk). This guarantees that the
      read() function always gets the proper clocksource pointer handed
      in.
      
      Since there is now no use for the tkr.read pointer, this patch
      also removes it, and to address stopping the fast timekeeper
      during suspend/resume, it introduces a dummy clocksource to use
      rather then just a dummy read function.
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Stephen Boyd <stephen.boyd@linaro.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Daniel Mentz <danielmentz@google.com>
      Link: http://lkml.kernel.org/r/1496965462-20003-2-git-send-email-john.stultz@linaro.orgSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1fecf397
    • Daniel Drake's avatar
      Input: i8042 - add Fujitsu Lifebook AH544 to notimeout list · 255ad85b
      Daniel Drake authored
      commit 817ae460 upstream.
      
      Without this quirk, the touchpad is not responsive on this product, with
      the following message repeated in the logs:
      
       psmouse serio1: bad data from KBC - timeout
      
      Add it to the notimeout list alongside other similar Fujitsu laptops.
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      255ad85b
    • Naveen N. Rao's avatar
      powerpc/kprobes: Pause function_graph tracing during jprobes handling · 3ee9033e
      Naveen N. Rao authored
      commit a9f8553e upstream.
      
      This fixes a crash when function_graph and jprobes are used together.
      This is essentially commit 237d28db ("ftrace/jprobes/x86: Fix
      conflict between jprobes and function graph tracing"), but for powerpc.
      
      Jprobes breaks function_graph tracing since the jprobe hook needs to use
      jprobe_return(), which never returns back to the hook, but instead to
      the original jprobe'd function. The solution is to momentarily pause
      function_graph tracing before invoking the jprobe hook and re-enable it
      when returning back to the original jprobe'd function.
      
      Fixes: 6794c782 ("powerpc64: port of the function graph tracer")
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Acked-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ee9033e
    • Eric W. Biederman's avatar
      signal: Only reschedule timers on signals timers have sent · bc7b3e99
      Eric W. Biederman authored
      commit 57db7e4a upstream.
      
      Thomas Gleixner  wrote:
      > The CRIU support added a 'feature' which allows a user space task to send
      > arbitrary (kernel) signals to itself. The changelog says:
      >
      >   The kernel prevents sending of siginfo with positive si_code, because
      >   these codes are reserved for kernel.  I think we can allow a task to
      >   send such a siginfo to itself.  This operation should not be dangerous.
      >
      > Quite contrary to that claim, it turns out that it is outright dangerous
      > for signals with info->si_code == SI_TIMER. The following code sequence in
      > a user space task allows to crash the kernel:
      >
      >    id = timer_create(CLOCK_XXX, ..... signo = SIGX);
      >    timer_set(id, ....);
      >    info->si_signo = SIGX;
      >    info->si_code = SI_TIMER:
      >    info->_sifields._timer._tid = id;
      >    info->_sifields._timer._sys_private = 2;
      >    rt_[tg]sigqueueinfo(..., SIGX, info);
      >    sigemptyset(&sigset);
      >    sigaddset(&sigset, SIGX);
      >    rt_sigtimedwait(sigset, info);
      >
      > For timers based on CLOCK_PROCESS_CPUTIME_ID, CLOCK_THREAD_CPUTIME_ID this
      > results in a kernel crash because sigwait() dequeues the signal and the
      > dequeue code observes:
      >
      >   info->si_code == SI_TIMER && info->_sifields._timer._sys_private != 0
      >
      > which triggers the following callchain:
      >
      >  do_schedule_next_timer() -> posix_cpu_timer_schedule() -> arm_timer()
      >
      > arm_timer() executes a list_add() on the timer, which is already armed via
      > the timer_set() syscall. That's a double list add which corrupts the posix
      > cpu timer list. As a consequence the kernel crashes on the next operation
      > touching the posix cpu timer list.
      >
      > Posix clocks which are internally implemented based on hrtimers are not
      > affected by this because hrtimer_start() can handle already armed timers
      > nicely, but it's a reliable way to trigger the WARN_ON() in
      > hrtimer_forward(), which complains about calling that function on an
      > already armed timer.
      
      This problem has existed since the posix timer code was merged into
      2.5.63. A few releases earlier in 2.5.60 ptrace gained the ability to
      inject not just a signal (which linux has supported since 1.0) but the
      full siginfo of a signal.
      
      The core problem is that the code will reschedule in response to
      signals getting dequeued not just for signals the timers sent but
      for other signals that happen to a si_code of SI_TIMER.
      
      Avoid this confusion by testing to see if the queued signal was
      preallocated as all timer signals are preallocated, and so far
      only the timer code preallocates signals.
      
      Move the check for if a timer needs to be rescheduled up into
      collect_signal where the preallocation check must be performed,
      and pass the result back to dequeue_signal where the code reschedules
      timers.   This makes it clear why the code cares about preallocated
      timers.
      Reported-by: default avatarThomas Gleixner <tglx@linutronix.de>
      History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
      Reference: 66dd34ad ("signal: allow to send any siginfo to itself")
      Reference: 1669ce53 ("Add PTRACE_GETSIGINFO and PTRACE_SETSIGINFO")
      Fixes: db8b50ba ("[PATCH] POSIX clocks & timers")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc7b3e99
    • Sebastian Parschauer's avatar
      HID: Add quirk for Dell PIXART OEM mouse · 005253ff
      Sebastian Parschauer authored
      commit 3db28271 upstream.
      
      This mouse is also known under other IDs. It needs the quirk
      ALWAYS_POLL or will disconnect in runlevel 1 or 3.
      Signed-off-by: default avatarSebastian Parschauer <sparschauer@suse.de>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      005253ff
    • Pavel Shilovsky's avatar
      CIFS: Improve readdir verbosity · 63ba840a
      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>
      63ba840a
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Preserve userspace HTM state properly · 824b9506
      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>
      824b9506
    • Ilya Matveychikov's avatar
      lib/cmdline.c: fix get_options() overflow while parsing ranges · 7b88f761
      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>
      7b88f761
    • NeilBrown's avatar
      autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL · b95aa98e
      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>
      b95aa98e
    • Kees Cook's avatar
      fs/exec.c: account for argv/envp pointers · 1d3d0f8b
      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>
      1d3d0f8b
  2. 26 Jun, 2017 18 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.74 · 22da7ca8
      Greg Kroah-Hartman authored
      22da7ca8
    • Hugh Dickins's avatar
      mm: fix new crash in unmapped_area_topdown() · 1f2284fa
      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>
      1f2284fa
    • Helge Deller's avatar
      Allow stack to grow up to address space limit · f41512c6
      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>
      f41512c6
    • Hugh Dickins's avatar
      mm: larger stack guard gap, between vmas · 4b359430
      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]
      [wt: backport to 4.4: adjust context ; drop ppc hugetlb_radix changes]
      Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      [gkh: minor build fixes for 4.4]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b359430
    • Thomas Gleixner's avatar
      alarmtimer: Rate limit periodic intervals · 26605a06
      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>
      
      26605a06
    • Paul Burton's avatar
      MIPS: Fix bnezc/jialc return address calculation · c24159ad
      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>
      c24159ad
    • Shuah Khan's avatar
      usb: dwc3: exynos fix axius clock error path to do cleanup · 94695386
      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>
      94695386
    • Thomas Gleixner's avatar
      alarmtimer: Prevent overflow of relative timers · aac7fa21
      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>
      aac7fa21
    • Heiner Kallweit's avatar
      genirq: Release resources in __setup_irq() error path · 4d4d501c
      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>
      4d4d501c
    • Yu Zhao's avatar
      swap: cond_resched in swap_cgroup_prepare() · 6af90091
      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>
      6af90091
    • James Morse's avatar
      mm/memory-failure.c: use compound_head() flags for huge pages · bfbd244c
      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>
      bfbd244c
    • Alan Stern's avatar
      USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks · f5dc6175
      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>
      f5dc6175
    • Corentin Labbe's avatar
      usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk · 89c15994
      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>
      89c15994
    • Dan Carpenter's avatar
      drivers/misc/c2port/c2port-duramar2150.c: checking for NULL instead of IS_ERR() · 5efd37fe
      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>
      5efd37fe
    • Chris Brandt's avatar
      usb: r8a66597-hcd: decrease timeout · ab29b21a
      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>
      ab29b21a
    • Chris Brandt's avatar
      usb: r8a66597-hcd: select a different endpoint on timeout · 4c7a6dd2
      Chris Brandt authored
      commit 1f873d85 upstream.
      
      If multiple endpoints on a single device have pending IN URBs and one
      endpoint times out due to NAKs (perfectly legal), select a different
      endpoint URB to try.
      The existing code only checked to see another device address has pending
      URBs and ignores other IN endpoints on the current device address. This
      leads to endpoints never getting serviced if one endpoint is using NAK as
      a flow control method.
      
      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>
      4c7a6dd2
    • Johan Hovold's avatar
      USB: gadget: dummy_hcd: fix hub-descriptor removable fields · 42c8b4b5
      Johan Hovold authored
      commit d81182ce upstream.
      
      Flag the first and only port as removable while also leaving the
      remaining bits (including the reserved bit zero) unset in accordance
      with the specifications:
      
      	"Within a byte, if no port exists for a given location, the bit
      	field representing the port characteristics shall be 0."
      
      Also add a comment marking the legacy PortPwrCtrlMask field.
      
      Fixes: 1cd8fd28 ("usb: gadget: dummy_hcd: add SuperSpeed support")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: Tatyana Brokhman <tlinder@codeaurora.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42c8b4b5
    • Arnd Bergmann's avatar
      pvrusb2: reduce stack usage pvr2_eeprom_analyze() · dc6ecba3
      Arnd Bergmann authored
      commit 6830733d upstream.
      
      The driver uses a relatively large data structure on the stack, which
      showed up on my radar as we get a warning with the "latent entropy"
      GCC plugin:
      
      drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]
      
      The warning is usually hidden as we raise the warning limit to 2048
      when the plugin is enabled, but I'd like to lower that again in the
      future, and making this function smaller helps to do that without
      build regressions.
      
      Further analysis shows that putting an 'i2c_client' structure on
      the stack is not really supported, as the embedded 'struct device'
      is not initialized here, and we are only saved by the fact that
      the function that is called here does not use the pointer at all.
      
      Fixes: d855497e ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc6ecba3