1. 13 11月, 2019 1 次提交
    • H
      ALSA: usb-audio: not submit urb for stopped endpoint · 52869931
      Henry Lin 提交于
      While output urb's snd_complete_urb() is executing, calling
      prepare_outbound_urb() may cause endpoint stopped before
      prepare_outbound_urb() returns and result in next urb submitted
      to stopped endpoint. usb-audio driver cannot re-use it afterwards as
      the urb is still hold by usb stack.
      
      This change checks EP_FLAG_RUNNING flag after prepare_outbound_urb() again
      to let snd_complete_urb() know the endpoint already stopped and does not
      submit next urb. Below kind of error will be fixed:
      
      [  213.153103] usb 1-2: timeout: still 1 active urbs on EP #1
      [  213.164121] usb 1-2: cannot submit urb 0, error -16: unknown error
      Signed-off-by: NHenry Lin <henryl@nvidia.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191113021420.13377-1-henryl@nvidia.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      52869931
  2. 11 11月, 2019 2 次提交
  3. 10 11月, 2019 1 次提交
  4. 07 11月, 2019 2 次提交
    • T
      Merge tag 'asoc-fix-v5.4-rc6' of... · df37d941
      Takashi Iwai 提交于
      Merge tag 'asoc-fix-v5.4-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: Fixes for v5.4
      
      These are a collection of fixes since v5.4-rc4 that have accumilated,
      they're all driver specific and there's nothing major in here so it's
      probably not essential to actually send them but I'll leave that call to
      you.
      df37d941
    • T
      ALSA: timer: Fix incorrectly assigned timer instance · e7af6307
      Takashi Iwai 提交于
      The clean up commit 41672c0c ("ALSA: timer: Simplify error path in
      snd_timer_open()") unified the error handling code paths with the
      standard goto, but it introduced a subtle bug: the timer instance is
      stored in snd_timer_open() incorrectly even if it returns an error.
      This may eventually lead to UAF, as spotted by fuzzer.
      
      The culprit is the snd_timer_open() code checks the
      SNDRV_TIMER_IFLG_EXCLUSIVE flag with the common variable timeri.
      This variable is supposed to be the newly created instance, but we
      (ab-)used it for a temporary check before the actual creation of a
      timer instance.  After that point, there is another check for the max
      number of instances, and it bails out if over the threshold.  Before
      the refactoring above, it worked fine because the code returned
      directly from that point.  After the refactoring, however, it jumps to
      the unified error path that stores the timeri variable in return --
      even if it returns an error.  Unfortunately this stored value is kept
      in the caller side (snd_timer_user_tselect()) in tu->timeri.  This
      causes inconsistency later, as if the timer was successfully
      assigned.
      
      In this patch, we fix it by not re-using timeri variable but a
      temporary variable for testing the exclusive connection, so timeri
      remains NULL at that point.
      
      Fixes: 41672c0c ("ALSA: timer: Simplify error path in snd_timer_open()")
      Reported-and-tested-by: NTristan Madani <tristmd@gmail.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191106165547.23518-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      e7af6307
  5. 06 11月, 2019 4 次提交
  6. 05 11月, 2019 1 次提交
  7. 04 11月, 2019 2 次提交
  8. 31 10月, 2019 1 次提交
    • T
      ALSA: timer: Fix mutex deadlock at releasing card · a3933186
      Takashi Iwai 提交于
      When a card is disconnected while in use, the system waits until all
      opened files are closed then releases the card.  This is done via
      put_device() of the card device in each device release code.
      
      The recently reported mutex deadlock bug happens in this code path;
      snd_timer_close() for the timer device deals with the global
      register_mutex and it calls put_device() there.  When this timer
      device is the last one, the card gets freed and it eventually calls
      snd_timer_free(), which has again the protection with the global
      register_mutex -- boom.
      
      Basically put_device() call itself is race-free, so a relative simple
      workaround is to move this put_device() call out of the mutex.  For
      achieving that, in this patch, snd_timer_close_locked() got a new
      argument to store the card device pointer in return, and each caller
      invokes put_device() with the returned object after the mutex unlock.
      Reported-and-tested-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a3933186
  9. 30 10月, 2019 1 次提交
    • T
      ALSA: hda - Fix mutex deadlock in HDMI codec driver · 302d5a80
      Takashi Iwai 提交于
      The commit ade49db3 ("ALSA: hda/hdmi - Allow audio component for
      AMD/ATI and Nvidia HDMI") introduced the spec->pcm_lock mutex lock to
      the whole generic_hdmi_init() function for avoiding the race with the
      audio component registration.  However, this caused a dead lock when
      the unsolicited event is handled without the audio component, as the
      codec gets runtime-resumed in hdmi_present_sense() which is already
      inside the spec->pcm_lock in its caller.
      
      For avoiding this deadlock, add a new mutex only for the audio
      component binding that is used in both generic_hdmi_init() and the
      audio notifier registration where the jack callbacks are handled /
      re-registered.
      
      Fixes: ade49db3 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI")
      Reported-and-tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://lore.kernel.org/r/s5himo7i89i.wl-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      302d5a80
  10. 28 10月, 2019 6 次提交
  11. 26 10月, 2019 1 次提交
  12. 24 10月, 2019 7 次提交
  13. 23 10月, 2019 1 次提交
  14. 22 10月, 2019 1 次提交
  15. 21 10月, 2019 4 次提交
  16. 19 10月, 2019 4 次提交
  17. 17 10月, 2019 1 次提交