1. 11 Jan, 2018 1 commit
    • Takashi Iwai's avatar
      ALSA: seq: Make ioctls race-free · b3defb79
      Takashi Iwai authored
      The ALSA sequencer ioctls have no protection against racy calls while
      the concurrent operations may lead to interfere with each other.  As
      reported recently, for example, the concurrent calls of setting client
      pool with a combination of write calls may lead to either the
      unkillable dead-lock or UAF.
      
      As a slightly big hammer solution, this patch introduces the mutex to
      make each ioctl exclusive.  Although this may reduce performance via
      parallel ioctl calls, usually it's not demanded for sequencer usages,
      hence it should be negligible.
      Reported-by: default avatarLuo Quan <a4651386@163.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b3defb79
  2. 10 Jan, 2018 3 commits
  3. 08 Jan, 2018 2 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Allow aborting mutex lock at OSS read/write loops · 900498a3
      Takashi Iwai authored
      PCM OSS read/write loops keep taking the mutex lock for the whole
      read/write, and this might take very long when the exceptionally high
      amount of data is given.  Also, since it invokes with mutex_lock(),
      the concurrent read/write becomes unbreakable.
      
      This patch tries to address these issues by replacing mutex_lock()
      with mutex_lock_interruptible(), and also splits / re-takes the lock
      at each read/write period chunk, so that it can switch the context
      more finely if requested.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      900498a3
    • Takashi Iwai's avatar
      ALSA: pcm: Abort properly at pending signal in OSS read/write loops · 29159a4e
      Takashi Iwai authored
      The loops for read and write in PCM OSS emulation have no proper check
      of pending signals, and they keep processing even after user tries to
      break.  This results in a very long delay, often seen as RCU stall
      when a huge unprocessed bytes remain queued.  The bug could be easily
      triggered by syzkaller.
      
      As a simple workaround, this patch adds the proper check of pending
      signals and aborts the loop appropriately.
      
      Reported-by: syzbot+993cb4cfcbbff3947c21@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      29159a4e
  4. 05 Jan, 2018 4 commits
    • Takashi Iwai's avatar
      ALSA: aloop: Fix racy hw constraints adjustment · 898dfe46
      Takashi Iwai authored
      The aloop driver tries to update the hw constraints of the connected
      target on the cable of the opened PCM substream.  This is done by
      adding the extra hw constraints rules referring to the substream
      runtime->hw fields, while the other substream may update the runtime
      hw of another side on the fly.
      
      This is, however, racy and may result in the inconsistent values when
      both PCM streams perform the prepare concurrently.  One of the reason
      is that it overwrites the other's runtime->hw field; which is not only
      racy but also broken when it's called before the open of another side
      finishes.  And, since the reference to runtime->hw isn't protected,
      the concurrent write may give the partial value update and become
      inconsistent.
      
      This patch is an attempt to fix and clean up:
      - The prepare doesn't change the runtime->hw of other side any longer,
        but only update the cable->hw that is referred commonly.
      - The extra rules refer to the loopback_pcm object instead of the
        runtime->hw.  The actual hw is deduced from cable->hw.
      - The extra rules take the cable_lock to protect against the race.
      
      Fixes: b1c73fc8 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      898dfe46
    • Takashi Iwai's avatar
      ALSA: aloop: Fix inconsistent format due to incomplete rule · b088b53e
      Takashi Iwai authored
      The extra hw constraint rule for the formats the aloop driver
      introduced has a slight flaw, where it doesn't return a positive value
      when the mask got changed.  It came from the fact that it's basically
      a copy&paste from snd_hw_constraint_mask64().  The original code is
      supposed to be a single-shot and it modifies the mask bits only once
      and never after, while what we need for aloop is the dynamic hw rule
      that limits the mask bits.
      
      This difference results in the inconsistent state, as the hw_refine
      doesn't apply the dependencies fully.  The worse and surprisingly
      result is that it causes a crash in OSS emulation when multiple
      full-duplex reads/writes are performed concurrently (I leave why it
      triggers Oops to readers as a homework).
      
      For fixing this, replace a few open-codes with the standard
      snd_mask_*() macros.
      
      Reported-by: syzbot+3902b5220e8ca27889ca@syzkaller.appspotmail.com
      Fixes: b1c73fc8 ("ALSA: snd-aloop: Fix hw_params restrictions and checking")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b088b53e
    • Takashi Iwai's avatar
      ALSA: aloop: Release cable upon open error path · 9685347a
      Takashi Iwai authored
      The aloop runtime object and its assignment in the cable are left even
      when opening a substream fails.  This doesn't mean any memory leak,
      but it still keeps the invalid pointer that may be referred by the
      another side of the cable spontaneously, which is a potential Oops
      cause.
      
      Clean up the cable assignment and the empty cable upon the error path
      properly.
      
      Fixes: 597603d6 ("ALSA: introduce the snd-aloop module for the PCM loopback")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9685347a
    • Takashi Iwai's avatar
      ALSA: pcm: Workaround for weird PulseAudio behavior on rewind error · fb51f1cd
      Takashi Iwai authored
      The commit 9027c463 ("ALSA: pcm: Call ack() whenever appl_ptr is
      updated") introduced the possible error code returned from the PCM
      rewind ioctl.  Basically the change was for handling the indirect PCM
      more correctly, but ironically, it caused rather a side-effect:
      PulseAudio gets pissed off when receiving an error from rewind, throws
      everything away and stops processing further, resulting in the
      silence.
      
      It's clearly a failure in the application side, so the best would be
      to fix that bug in PA.  OTOH, PA is mostly the only user of the rewind
      feature, so it's not good to slap the sole customer.
      
      This patch tries to mitigate the situation: instead of returning an
      error, now the rewind ioctl returns zero when the driver can't rewind.
      It indicates that no rewind was performed, so the behavior is
      consistent, at least.
      
      Fixes: 9027c463 ("ALSA: pcm: Call ack() whenever appl_ptr is updated")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fb51f1cd
  5. 04 Jan, 2018 1 commit
  6. 02 Jan, 2018 1 commit
    • Takashi Iwai's avatar
      ALSA: pcm: Remove incorrect snd_BUG_ON() usages · fe08f34d
      Takashi Iwai authored
      syzkaller triggered kernel warnings through PCM OSS emulation at
      closing a stream:
        WARNING: CPU: 0 PID: 3502 at sound/core/pcm_lib.c:1635
        snd_pcm_hw_param_first+0x289/0x690 sound/core/pcm_lib.c:1635
        Call Trace:
        ....
         snd_pcm_hw_param_near.constprop.27+0x78d/0x9a0 sound/core/oss/pcm_oss.c:457
         snd_pcm_oss_change_params+0x17d3/0x3720 sound/core/oss/pcm_oss.c:969
         snd_pcm_oss_make_ready+0xaa/0x130 sound/core/oss/pcm_oss.c:1128
         snd_pcm_oss_sync+0x257/0x830 sound/core/oss/pcm_oss.c:1638
         snd_pcm_oss_release+0x20b/0x280 sound/core/oss/pcm_oss.c:2431
         __fput+0x327/0x7e0 fs/file_table.c:210
         ....
      
      This happens while it tries to open and set up the aloop device
      concurrently.  The warning above (invoked from snd_BUG_ON() macro) is
      to detect the unexpected logical error where snd_pcm_hw_refine() call
      shouldn't fail.  The theory is true for the case where the hw_params
      config rules are static.  But for an aloop device, the hw_params rule
      condition does vary dynamically depending on the connected target;
      when another device is opened and changes the parameters, the device
      connected in another side is also affected, and it caused the error
      from snd_pcm_hw_refine().
      
      That is, the simplest "solution" for this is to remove the incorrect
      assumption of static rules, and treat such an error as a normal error
      path.  As there are a couple of other places using snd_BUG_ON()
      incorrectly, this patch removes these spurious snd_BUG_ON() calls.
      
      Reported-by: syzbot+6f11c7e2a1b91d466432@syzkaller.appspotmail.com
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fe08f34d
  7. 27 Dec, 2017 1 commit
  8. 22 Dec, 2017 4 commits
  9. 20 Dec, 2017 8 commits
  10. 19 Dec, 2017 3 commits
    • Brian Norris's avatar
      ASoC: rt5514-spi: only enable wakeup when fully initialized · 20220945
      Brian Norris authored
      If an rt5514-spi device is probed but the platform hasn't linked it in,
      we might never fully request the SPI IRQ, nor configure the rt5514 DSP,
      but we still might try to enable the SPI IRQ (enable_irq_wake()). This
      is bad, and among other things, can cause the interrupt to trigger every
      time we try to suspend the system (e.g., because the interrupt trigger
      setting was never set properly).
      
      Instead of setting our wakeup capabilities in the SPI driver probe
      routine, let's wait until we've actually requested the IRQ.
      
      Fixes issues seen on the "kevin" Chromebook (Samsung Chromebook Plus).
      
      Fixes: 58f1c07d ("ASoC: rt5514: Voice wakeup support.")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      20220945
    • Abhijeet Kumar's avatar
      ASoC: nau8825: fix issue that pop noise when start capture · d070f7c7
      Abhijeet Kumar authored
      In skylake platform, we hear a loud pop noise(0 dB) at start of
      audio capture power up sequence. This patch removes the pop noise
      from the recording by adding a delay before enabling ADC.
      Signed-off-by: default avatarAbhijeet Kumar <abhijeet.kumar@intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      d070f7c7
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix the missing ctl name suffix at parsing SU · 5a15f289
      Takashi Iwai authored
      The commit 89b89d12 ("ALSA: usb-audio: Add check return value for
      usb_string()") added the check of the return value from
      snd_usb_copy_string_desc(), which is correct per se, but it introduced
      a regression.  In the original code, either the "Clock Source",
      "Playback Source" or "Capture Source" suffix is added after the
      terminal string, while the commit changed it to add the suffix only
      when get_term_name() is failing.  It ended up with an incorrect ctl
      name like "PCM" instead of "PCM Capture Source".
      
      Also, even the original code has a similar bug: when the ctl name is
      generated from snd_usb_copy_string_desc() for the given iSelector, it
      also doesn't put the suffix.
      
      This patch addresses these issues: the suffix is added always when no
      static mapping is found.  Also the patch tries to put more comments
      and cleans up the if/else block for better readability in order to
      avoid the same pitfall again.
      
      Fixes: 89b89d12 ("ALSA: usb-audio: Add check return value for usb_string()")
      Reported-and-tested-by: default avatarMauro Santos <registo.mailling@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5a15f289
  11. 18 Dec, 2017 2 commits
    • Kailang Yang's avatar
      ALSA: hda/realtek - Fix Dell AIO LineOut issue · 92266651
      Kailang Yang authored
      Dell AIO had LineOut jack.
      Add LineOut verb into this patch.
      
      [ Additional notes:
        the ALC274 codec seems requiring the fixed pin / DAC connections for
        HP / line-out pins for enabling EQ for speakers; i.e. the HP / LO
        pins expect to be connected with NID 0x03 while keeping the speaker
        with NID 0x02.  However, by adding a new line-out pin, the
        auto-parser assigns the NID 0x02 for HP/LO pins as primary outputs.
        As an easy workaround, we provide the preferred_pairs[] to map
        forcibly for these pins. -- tiwai ]
      
      Fixes: 75ee94b2 ("ALSA: hda - fix headset mic problem for Dell machines with alc274")
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      92266651
    • Linus Torvalds's avatar
      Linux 4.15-rc4 · 1291a0d5
      Linus Torvalds authored
      1291a0d5
  12. 17 Dec, 2017 10 commits