1. 01 7月, 2014 6 次提交
  2. 30 6月, 2014 1 次提交
  3. 27 6月, 2014 7 次提交
  4. 26 6月, 2014 3 次提交
    • T
      Merge branch 'for-linus' into for-next · 7e9c2eb6
      Takashi Iwai 提交于
      7e9c2eb6
    • M
      ALSA: hda - restore BCLK M/N values when resuming HSW/BDW display controller · a07187c9
      Mengdong Lin 提交于
      For Intel Haswell/Broadwell display HD-A controller, the 24MHz HD-A link BCLK
      is converted from Core Display Clock (CDCLK): BCLK = CDCLK * M / N
      And there are two registers EM4 and EM5 to program M, N value respectively.
      The EM4/EM5 values will be lost and when the display power well is disabled.
      
      BIOS programs CDCLK selected by OEM and EM4/EM5, but BIOS has no idea about
      display power well on/off at runtime. So the M/N can be wrong if non-default
      CDCLK is used when the audio controller resumes, which results in an invalid
      BCLK and abnormal audio playback rate. So this patch saves and restores valid
      M/N values on controller suspend/resume.
      
      And 'struct hda_intel' is defined to contain standard HD-A 'struct azx' and
      Intel specific fields, as Takashi suggested.
      Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      a07187c9
    • T
      ALSA: usb-audio: Fix races at disconnection and PCM closing · 92a586bd
      Takashi Iwai 提交于
      When a USB-audio device is disconnected while PCM is still running, we
      still see some race: the disconnect callback calls
      snd_usb_endpoint_free() that calls release_urbs() and then kfree()
      while a PCM stream would be closed at the same time and calls
      stop_endpoints() that leads to wait_clear_urbs().  That is, the EP
      object might be deallocated while a PCM stream is syncing with
      wait_clear_urbs() with the same EP.
      
      Basically calling multiple wait_clear_urbs() would work fine, also
      calling wait_clear_urbs() and release_urbs() would work, too, as
      wait_clear_urbs() just reads some fields in ep.  The problem is the
      succeeding kfree() in snd_pcm_endpoint_free().
      
      This patch moves out the EP deallocation into the later point, the
      destructor callback.  At this stage, all PCMs must have been already
      closed, so it's safe to free the objects.
      Reported-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      92a586bd
  5. 25 6月, 2014 6 次提交
  6. 24 6月, 2014 4 次提交
  7. 23 6月, 2014 6 次提交
  8. 18 6月, 2014 7 次提交
    • T
      Merge branch 'topic/core-vuln-fixes' into for-linus · 8d42fda9
      Takashi Iwai 提交于
      8d42fda9
    • T
      Merge tag 'asoc-v3.16-rc1' of... · 6c0c9a3d
      Takashi Iwai 提交于
      Merge tag 'asoc-v3.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: Fixes for v3.16
      
      Quite a few build coverage fixes in here among the usual small driver
      fixes includling the sigmadsp change from Lars - moving the driver to
      separate modules per bus (which is basically just code motion) avoids
      issues with some combinations of buses being enabled.
      6c0c9a3d
    • L
      ALSA: control: Make sure that id->index does not overflow · 883a1d49
      Lars-Peter Clausen 提交于
      The ALSA control code expects that the range of assigned indices to a control is
      continuous and does not overflow. Currently there are no checks to enforce this.
      If a control with a overflowing index range is created that control becomes
      effectively inaccessible and unremovable since snd_ctl_find_id() will not be
      able to find it. This patch adds a check that makes sure that controls with a
      overflowing index range can not be created.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Acked-by: NJaroslav Kysela <perex@perex.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      883a1d49
    • L
      ALSA: control: Handle numid overflow · ac902c11
      Lars-Peter Clausen 提交于
      Each control gets automatically assigned its numids when the control is created.
      The allocation is done by incrementing the numid by the amount of allocated
      numids per allocation. This means that excessive creation and destruction of
      controls (e.g. via SNDRV_CTL_IOCTL_ELEM_ADD/REMOVE) can cause the id to
      eventually overflow. Currently when this happens for the control that caused the
      overflow kctl->id.numid + kctl->count will also over flow causing it to be
      smaller than kctl->id.numid. Most of the code assumes that this is something
      that can not happen, so we need to make sure that it won't happen
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Acked-by: NJaroslav Kysela <perex@perex.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      ac902c11
    • L
      ALSA: control: Don't access controls outside of protected regions · fd9f26e4
      Lars-Peter Clausen 提交于
      A control that is visible on the card->controls list can be freed at any time.
      This means we must not access any of its memory while not holding the
      controls_rw_lock. Otherwise we risk a use after free access.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Acked-by: NJaroslav Kysela <perex@perex.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      fd9f26e4
    • L
      ALSA: control: Fix replacing user controls · 82262a46
      Lars-Peter Clausen 提交于
      There are two issues with the current implementation for replacing user
      controls. The first is that the code does not check if the control is actually a
      user control and neither does it check if the control is owned by the process
      that tries to remove it. That allows userspace applications to remove arbitrary
      controls, which can cause a user after free if a for example a driver does not
      expect a control to be removed from under its feed.
      
      The second issue is that on one hand when a control is replaced the
      user_ctl_count limit is not checked and on the other hand the user_ctl_count is
      increased (even though the number of user controls does not change). This allows
      userspace, once the user_ctl_count limit as been reached, to repeatedly replace
      a control until user_ctl_count overflows. Once that happens new controls can be
      added effectively bypassing the user_ctl_count limit.
      
      Both issues can be fixed by instead of open-coding the removal of the control
      that is to be replaced to use snd_ctl_remove_user_ctl(). This function does
      proper permission checks as well as decrements user_ctl_count after the control
      has been removed.
      
      Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at
      beginning of the function if the control already exists is removed. This is not
      a problem though since the check is quite useless, because the lock that is
      protecting the control list is released between the check and before adding the
      new control to the list, which means that it is possible that a different
      control with the same settings is added to the list after the check. Luckily
      there is another check that is done while holding the lock in snd_ctl_add(), so
      we'll rely on that to make sure that the same control is not added twice.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Acked-by: NJaroslav Kysela <perex@perex.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      82262a46
    • L
      ALSA: control: Protect user controls against concurrent access · 07f4d9d7
      Lars-Peter Clausen 提交于
      The user-control put and get handlers as well as the tlv do not protect against
      concurrent access from multiple threads. Since the state of the control is not
      updated atomically it is possible that either two write operations or a write
      and a read operation race against each other. Both can lead to arbitrary memory
      disclosure. This patch introduces a new lock that protects user-controls from
      concurrent access. Since applications typically access controls sequentially
      than in parallel a single lock per card should be fine.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Acked-by: NJaroslav Kysela <perex@perex.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      07f4d9d7