1. 26 Mar, 2015 1 commit
  2. 18 Mar, 2015 1 commit
  3. 06 Feb, 2015 1 commit
  4. 14 Nov, 2014 1 commit
  5. 30 Oct, 2014 1 commit
  6. 05 Oct, 2014 2 commits
  7. 26 Jun, 2014 5 commits
    • Lars-Peter Clausen's avatar
      ALSA: control: Make sure that id->index does not overflow · 7fba24c6
      Lars-Peter Clausen authored
      commit 883a1d49f0d77d30012f114b2e19fc141beb3e8e upstream.
      
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Acked-by: default avatarJaroslav Kysela <perex@perex.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7fba24c6
    • Lars-Peter Clausen's avatar
      ALSA: control: Handle numid overflow · 0255758b
      Lars-Peter Clausen authored
      commit ac902c112d90a89e59916f751c2745f4dbdbb4bd upstream.
      
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Acked-by: default avatarJaroslav Kysela <perex@perex.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0255758b
    • Lars-Peter Clausen's avatar
      ALSA: control: Don't access controls outside of protected regions · 9abd9486
      Lars-Peter Clausen authored
      commit fd9f26e4eca5d08a27d12c0933fceef76ed9663d upstream.
      
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Acked-by: default avatarJaroslav Kysela <perex@perex.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9abd9486
    • Lars-Peter Clausen's avatar
      ALSA: control: Fix replacing user controls · adbb1449
      Lars-Peter Clausen authored
      commit 82262a46627bebb0febcc26664746c25cef08563 upstream.
      
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Acked-by: default avatarJaroslav Kysela <perex@perex.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      adbb1449
    • Lars-Peter Clausen's avatar
      ALSA: control: Protect user controls against concurrent access · be3bae53
      Lars-Peter Clausen authored
      commit 07f4d9d74a04aa7c72c5dae0ef97565f28f17b92 upstream.
      
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Acked-by: default avatarJaroslav Kysela <perex@perex.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be3bae53
  8. 31 Mar, 2014 1 commit
  9. 09 Jan, 2014 1 commit
  10. 29 Nov, 2013 2 commits
    • Vinod Koul's avatar
      ALSA: compress: fix drain calls blocking other compress functions (v6) · 86e6de78
      Vinod Koul authored
      commit f44f2a5417b2968a8724b352cc0b2545a6bcb1f4 upstream.
      
      The drain and drain_notify callback were blocked by low level driver
      until the draining was complete. Due to this being invoked with big
      fat mutex held, others ops like reading timestamp, calling pause, drop
      were blocked.
      
      So to fix this we add a new snd_compr_drain_notify() API. This would
      be required to be invoked by low level driver when drain or partial
      drain has been completed by the DSP. Thus we make the drain and
      partial_drain callback as non blocking and driver returns immediately
      after notifying DSP.  The waiting is done while releasing the lock so
      that other ops can go ahead.
      
      [ The commit 917f4b5cba78 was wrongly applied from the preliminary
        patch.  This commit corrects to the final version.
        Sorry for inconvenience!  -- tiwai ]
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86e6de78
    • Vinod Koul's avatar
      ALSA: compress: fix drain calls blocking other compress functions · 16442d4f
      Vinod Koul authored
      commit 917f4b5cba78980a527098a910d94139d3e82c8d upstream.
      
      The drain and drain_notify callback were blocked by low level driver untill the
      draining was complete. Due to this being invoked with big fat mutex held, others
      ops like reading timestamp, calling pause, drop were blocked.
      
      So to fix this we add a new snd_compr_drain_notify() API. This would be required
      to be invoked by low level driver when drain or partial drain has been completed
      by the DSP. Thus we make the drain and partial_drain callback as non blocking
      and driver returns immediately after notifying DSP.
      The waiting is done while relasing the lock so that other ops can go ahead.
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16442d4f
  11. 13 Nov, 2013 1 commit
    • Russell King's avatar
      ALSA: fix oops in snd_pcm_info() caused by ASoC DPCM · 58dc7706
      Russell King authored
      commit a4461f41b94cb52e0141af717dcf4ef6558c8e2e upstream.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000008
      pgd = d5300000
      [00000008] *pgd=0d265831, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] PREEMPT ARM
      CPU: 0 PID: 2295 Comm: vlc Not tainted 3.11.0+ #755
      task: dee74800 ti: e213c000 task.ti: e213c000
      PC is at snd_pcm_info+0xc8/0xd8
      LR is at 0x30232065
      pc : [<c031b52c>]    lr : [<30232065>]    psr: a0070013
      sp : e213dea8  ip : d81cb0d0  fp : c05f7678
      r10: c05f7770  r9 : fffffdfd  r8 : 00000000
      r7 : d8a968a8  r6 : d8a96800  r5 : d8a96200  r4 : d81cb000
      r3 : 00000000  r2 : d81cb000  r1 : 00000001  r0 : d8a96200
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 10c5387d  Table: 15300019  DAC: 00000015
      Process vlc (pid: 2295, stack limit = 0xe213c248)
      [<c031b52c>] (snd_pcm_info) from [<c031b570>] (snd_pcm_info_user+0x34/0x9c)
      [<c031b570>] (snd_pcm_info_user) from [<c03164a4>] (snd_pcm_control_ioctl+0x274/0x280)
      [<c03164a4>] (snd_pcm_control_ioctl) from [<c0311458>] (snd_ctl_ioctl+0xc0/0x55c)
      [<c0311458>] (snd_ctl_ioctl) from [<c00eca84>] (do_vfs_ioctl+0x80/0x31c)
      [<c00eca84>] (do_vfs_ioctl) from [<c00ecd5c>] (SyS_ioctl+0x3c/0x60)
      [<c00ecd5c>] (SyS_ioctl) from [<c000e500>] (ret_fast_syscall+0x0/0x48)
      Code: e1a00005 e59530dc e3a01001 e1a02004 (e5933008)
      ---[ end trace cb3d9bdb8dfefb3c ]---
      
      This is provoked when the ASoC front end is open along with its backend,
      (which causes the backend to have a runtime assigned to it) and then the
      SNDRV_CTL_IOCTL_PCM_INFO is requested for the (visible) backend device.
      
      Resolve this by ensuring that ASoC internal backend devices are not
      visible to userspace, just as the commentry for snd_pcm_new_internal()
      says it should be.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58dc7706
  12. 05 Oct, 2013 1 commit
  13. 12 Aug, 2013 1 commit
  14. 25 Jul, 2013 1 commit
  15. 15 Jun, 2013 1 commit
  16. 08 May, 2013 1 commit
  17. 01 May, 2013 2 commits
  18. 29 Apr, 2013 1 commit
  19. 22 Apr, 2013 2 commits
  20. 21 Apr, 2013 6 commits
  21. 19 Apr, 2013 1 commit
  22. 18 Apr, 2013 1 commit
    • Daniel Mack's avatar
      ALSA: add DSD formats · ef7a4f97
      Daniel Mack authored
      This patch adds two formats for Direct Stream Digital (DSD), a
      pulse-density encoding format which is described here:
      https://en.wikipedia.org/wiki/Direct_Stream_Digital
      
      DSD operates on 2.8, 5.6 or 11.2MHz sample rates and as a 1-bit
      stream.
      
      The two new types added by this patch describe streams that are capable
      of handling DSD samples in DOP format as 8-bit or in 16-bit (or at a x8
      or x16 data rate, respectively).
      
      DSD itself specifies samples in *bit*, while DOP and ALSA handle them
      as *bytes*. Hence, a factor of 8 or 16 has to be applied for the sample
      rare configuration, according to the following table:
      
                                                        configured hardware
              176.4KHz   352.8kHz   705.6KHz     <----       sample rate
      
      8-bit                2.8MHz     5.6MHz
      16-bit    2.8Mhz     5.6MHz    11.2MHz
      
               `-----------------------------'
                   actual DSD sample rates
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ef7a4f97
  23. 09 Apr, 2013 2 commits
  24. 13 Mar, 2013 2 commits
  25. 12 Mar, 2013 1 commit