Skip to content
Snippets Groups Projects
  1. Jul 06, 2016
    • Alan Stern's avatar
      USB: fix invalid memory access in hub_activate() · 9578569f
      Alan Stern authored
      
      Commit 8520f380 ("USB: change hub initialization sleeps to
      delayed_work") changed the hub_activate() routine to make part of it
      run in a workqueue.  However, the commit failed to take a reference to
      the usb_hub structure or to lock the hub interface while doing so.  As
      a result, if a hub is plugged in and quickly unplugged before the work
      routine can run, the routine will try to access memory that has been
      deallocated.  Or, if the hub is unplugged while the routine is
      running, the memory may be deallocated while it is in active use.
      
      This patch fixes the problem by taking a reference to the usb_hub at
      the start of hub_activate() and releasing it at the end (when the work
      is finished), and by locking the hub interface while the work routine
      is running.  It also adds a check at the start of the routine to see
      if the hub has already been disconnected, in which nothing should be
      done.
      
      CVE:CVE-2015-8816 Bug:ANDROID-28712303
      
      Change-Id: I4a3e860c0af40b676e420fec8c1980a4e9aba917
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarAlexandru Cornea <alexandru.cornea@intel.com>
      Tested-by: default avatarAlexandru Cornea <alexandru.cornea@intel.com>
      Fixes: 8520f380 ("USB: change hub initialization sleeps to delayed_work")
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. Jun 07, 2016
  3. May 18, 2016
  4. May 03, 2016
    • Zhao Xuewen's avatar
      pipe: Fix buffer offset after partially failed read · 7fabb579
      Zhao Xuewen authored
      Quoting the RHEL advisory:
      
      > It was found that the fix for CVE-2015-1805 incorrectly kept buffer
      > offset and buffer length in sync on a failed atomic read, potentially
      > resulting in a pipe buffer state corruption. A local, unprivileged user
      > could use this flaw to crash the system or leak kernel memory to user
      > space. (CVE-2016-0774, Moderate)
      
      The same flawed fix was applied to stable branches from 2.6.32.y to
      3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
      We need to give pipe_iov_copy_to_user() a separate offset variable
      and only update the buffer offset if it succeeds.
      
      CVE-2016-0774 Bug:ANDROID-27721803
      
      Change-Id: I988802f38acf40c7671fa0978880928b02d29b56
      References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
      
      
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      (cherry picked from commit feae3ca2)
      7fabb579
    • Zhao Xuewen's avatar
      ALSA: timer: Harden slave timer list handling · dc606a21
      Zhao Xuewen authored
      
      A slave timer instance might be still accessible in a racy way while
      operating the master instance as it lacks of locking.  Since the
      master operation is mostly protected with timer->lock, we should cope
      with it while changing the slave instance, too.  Also, some linked
      lists (active_list and ack_list) of slave instances aren't unlinked
      immediately at stopping or closing, and this may lead to unexpected
      accesses.
      
      This patch tries to address these issues.  It adds spin lock of
      timer->lock (either from master or slave, which is equivalent) in a
      few places.  For avoiding a deadlock, we ensure that the global
      slave_active_lock is always locked at first before each timer lock.
      
      Also, ack and active_list of slave instances are properly unlinked at
      snd_timer_stop() and snd_timer_close().
      
      Last but not least, remove the superfluous call of _snd_timer_stop()
      at removing slave links.  This is a noop, and calling it may confuse
      readers wrt locking.  Further cleanup will follow in a later patch.
      
      Actually we've got reports of use-after-free by syzkaller fuzzer, and
      this hopefully fixes these issues.
      
      CVE-2016-2438 Bug:ANDROID-26636060
      
      Change-Id: I86feccec1bf3c800c1eef280f7f12c79d12e1f60
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      dc606a21
  5. Apr 26, 2016
    • Zhao Xuewen's avatar
      HSUART:fix the hsuart multi-thread sync issue · e3a2c12d
      Zhao Xuewen authored
      
      Fix a multi thread sync issue descript as blew steps, this issue case BT HCI command timeout issue.
      a)sps connection can be closed in msm_hs_check_clock_off(the first time).
      b)msm_hs_check_clock_off return 0 after send a clk_off_timer msg to close sps connection
      c)when clk_off_timer is timeout, hsuart_clock_off_work will be invoked, so msm_hs_check_clock_off is invoked for the second time
      d)if there is a data/command comes from stack now, uart circular buf won't be empty, that meas uart_circ_empty(tx_buf) will return false
      e)if uart_circ_empty(tx_buf) return fasle, msm_hs_check_clock_off only set msm_uport->clk_state to MSM_HS_CLK_ON.
        but the sps connection will not be opened any more.
      f)now if there a data/command from stack again
        because the sps connection is still close, so the uart can't thansfer the command/data any more.
        so here open sps connection again
      
      BUG=27536255
      Change-Id: Ia5791af06ea7b7e898edcf2536b04179545df9b9
      Signed-off-by: default avatarz00184990 <z00184990@notesmail.huawei.com>
      (cherry picked from commit a4eae2c1)
      e3a2c12d
  6. Apr 12, 2016
  7. Apr 11, 2016
  8. Apr 08, 2016
  9. Apr 05, 2016
  10. Mar 23, 2016
  11. Feb 02, 2016
  12. Feb 01, 2016
  13. Jan 29, 2016
    • Jacky Cheung's avatar
      Add Nitrous driver for BT power management. · 7804a4c2
      Jacky Cheung authored
      It is specific to MSM host with BCM BT chips in its current form.  On Tx,
      the wake_peer hook is called by the serial core to wake up the serial
      driver and to toggle the dev wake gpio.  On Rx, the driver listens to the
      host_wake gpio state to also wake up the serial driver to receive incoming data.
      
      The driver is also registerd to handle rfkill state changes.
      
      Change-Id: I1356f64e9c6f42a24a09f39c4f8a5258e93de602
      7804a4c2
    • Jacky Cheung's avatar
      Add wake_peer hook to MSM HS UART driver. · 787108b3
      Jacky Cheung authored
      wake_peer hook is used to do BT chip-specific power management on Tx
      (e.g. toggling of BT device wake gpio).
      
      Change-Id: I7fdf5f173eea41fe791ce77c0438f814606353bf
      787108b3
  14. Jan 28, 2016