1. 20 Sep, 2022 4 commits
  2. 19 Sep, 2022 1 commit
  3. 17 Sep, 2022 1 commit
  4. 16 Sep, 2022 1 commit
  5. 15 Sep, 2022 6 commits
  6. 14 Sep, 2022 1 commit
  7. 13 Sep, 2022 7 commits
  8. 12 Sep, 2022 2 commits
  9. 10 Sep, 2022 1 commit
  10. 09 Sep, 2022 3 commits
  11. 08 Sep, 2022 1 commit
  12. 07 Sep, 2022 2 commits
    • Takashi Iwai's avatar
      ALSA: usb-audio: Clear fixed clock rate at closing EP · 809f44a0
      Takashi Iwai authored
      The recent commit c11117b6 ("ALSA: usb-audio: Refcount multiple
      accesses on the single clock") tries to manage the clock rate shared
      by several endpoints.  This was intended for avoiding the unmatched
      rate by a different endpoint, but unfortunately, it introduced a
      regression for PulseAudio and pipewire, too; those applications try to
      probe the multiple possible rates (44.1k and 48kHz) and setting up the
      normal rate fails but only the last rate is applied.
      
      The cause is that the last sample rate is still left to the clock
      reference even after closing the endpoint, and this value is still
      used at the next open.  It happens only when applications set up via
      PCM prepare but don't start/stop the stream; the rate is reset when
      the stream is stopped, but it's not cleared at close.
      
      This patch addresses the issue above, simply by clearing the rate set
      in the clock reference at the last close of each endpoint.
      
      Fixes: c11117b6 ("ALSA: usb-audio: Refcount multiple accesses on the single clock")
      Reported-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Tested-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/all/YxXIWv8dYmg1tnXP@zx2c4.com/
      Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2620
      Link: https://lore.kernel.org/r/20220907100421.6443-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      809f44a0
    • Tasos Sahanidis's avatar
      ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc() · d29f5905
      Tasos Sahanidis authored
      The voice allocator sometimes begins allocating from near the end of the
      array and then wraps around, however snd_emu10k1_pcm_channel_alloc()
      accesses the newly allocated voices as if it never wrapped around.
      
      This results in out of bounds access if the first voice has a high enough
      index so that first_voice + requested_voice_count > NUM_G (64).
      The more voices are requested, the more likely it is for this to occur.
      
      This was initially discovered using PipeWire, however it can be reproduced
      by calling aplay multiple times with 16 channels:
      aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
      
      UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
      index 65 is out of range for type 'snd_emu10k1_voice [64]'
      CPU: 1 PID: 31977 Comm: aplay Tainted: G        W IOE      6.0.0-rc2-emu10k1+ #7
      Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002    07/22/2010
      Call Trace:
      <TASK>
      dump_stack_lvl+0x49/0x63
      dump_stack+0x10/0x16
      ubsan_epilogue+0x9/0x3f
      __ubsan_handle_out_of_bounds.cold+0x44/0x49
      snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]
      snd_pcm_hw_params+0x29f/0x600 [snd_pcm]
      snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]
      ? exit_to_user_mode_prepare+0x35/0x170
      ? do_syscall_64+0x69/0x90
      ? syscall_exit_to_user_mode+0x26/0x50
      ? do_syscall_64+0x69/0x90
      ? exit_to_user_mode_prepare+0x35/0x170
      snd_pcm_ioctl+0x27/0x40 [snd_pcm]
      __x64_sys_ioctl+0x95/0xd0
      do_syscall_64+0x5c/0x90
      ? do_syscall_64+0x69/0x90
      ? do_syscall_64+0x69/0x90
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      Signed-off-by: default avatarTasos Sahanidis <tasos@tasossah.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/3707dcab-320a-62ff-63c0-73fc201ef756@tasossah.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d29f5905
  13. 06 Sep, 2022 8 commits
  14. 05 Sep, 2022 2 commits