1. 15 Oct, 2021 3 commits
  2. 14 Oct, 2021 2 commits
  3. 13 Oct, 2021 1 commit
  4. 12 Oct, 2021 4 commits
  5. 11 Oct, 2021 3 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl · 228af5a4
      Takashi Iwai authored
      Michael Forney reported an incorrect padding type that was defined in
      the commit 80fe7430 ("ALSA: add new 32-bit layout for
      snd_pcm_mmap_status/control") for PCM control mmap data.
      His analysis is correct, and this caused the misplacements of PCM
      control data on 32bit arch and 32bit compat mode.
      
      The bug is that the __pad2 definition in __snd_pcm_mmap_control64
      struct was wrongly with __pad_before_uframe, which should have been
      __pad_after_uframe instead.  This struct is used in SYNC_PTR ioctl and
      control mmap.  Basically this bug leads to two problems:
      
      - The offset of avail_min field becomes wrong, it's placed right after
        appl_ptr without padding on little-endian
      
      - When appl_ptr and avail_min are read as 64bit values in kernel side,
        the values become either zero or corrupted (mixed up)
      
      One good news is that, because both user-space and kernel
      misunderstand the wrong offset, at least, 32bit application running on
      32bit kernel works as is.  Also, 64bit applications are unaffected
      because the padding size is zero.  The remaining problem is the 32bit
      compat mode; as mentioned in the above, avail_min is placed right
      after appl_ptr on little-endian archs, 64bit kernel reads bogus values
      for appl_ptr updates, which may lead to streaming bugs like jumping,
      XRUN or whatever unexpected.
      (However, we haven't heard any serious bug reports due to this over
      years, so practically seen, it's fairly safe to assume that the impact
      by this bug is limited.)
      
      Ideally speaking, we should correct the wrong mmap status control
      definition.  But this would cause again incompatibility with the
      existing binaries, and fixing it (e.g. by renumbering ioctls) would be
      really messy.
      
      So, as of this patch, we only correct the behavior of 32bit compat
      mode and keep the rest as is.  Namely, the SYNC_PTR ioctl is now
      handled differently in compat mode to read/write the 32bit values at
      the right offsets.  The control mmap of 32bit apps on 64bit kernels
      has been already disabled (which is likely rather an overlook, but
      this worked fine at this time :), so covering SYNC_PTR ioctl should
      suffice as a fallback.
      
      Fixes: 80fe7430 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control")
      Reported-by: default avatarMichael Forney <mforney@mforney.org>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: <stable@vger.kernel.org>
      Cc: Rich Felker <dalias@libc.org>
      Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org
      Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      228af5a4
    • Yang Yingliang's avatar
      ASoC: soc-core: fix null-ptr-deref in snd_soc_del_component_unlocked() · c448b7aa
      Yang Yingliang authored
      'component' is allocated in snd_soc_register_component(), but component->list
      is not initalized, this may cause snd_soc_del_component_unlocked() deref null
      ptr in the error handing case.
      
      KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
      RIP: 0010:__list_del_entry_valid+0x81/0xf0
      Call Trace:
       snd_soc_del_component_unlocked+0x69/0x1b0 [snd_soc_core]
       snd_soc_add_component.cold+0x54/0x6c [snd_soc_core]
       snd_soc_register_component+0x70/0x90 [snd_soc_core]
       devm_snd_soc_register_component+0x5e/0xd0 [snd_soc_core]
       tas2552_probe+0x265/0x320 [snd_soc_tas2552]
       ? tas2552_component_probe+0x1e0/0x1e0 [snd_soc_tas2552]
       i2c_device_probe+0xa31/0xbe0
      
      Fix by adding INIT_LIST_HEAD() to snd_soc_component_initialize().
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Link: https://lore.kernel.org/r/20211009065840.3196239-1-yangyingliang@huawei.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c448b7aa
    • Cameron Berkenpas's avatar
      ALSA: hda/realtek: Fix for quirk to enable speaker output on the Lenovo 13s Gen2 · 023a062f
      Cameron Berkenpas authored
      The previous patch's HDA verb initialization for the Lenovo 13s
      sequence was slightly off. This updated verb sequence has been tested
      and confirmed working.
      
      Fixes: ad7cc2d4 ("ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops.")
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarCameron Berkenpas <cam@neo-zeon.de>
      Link: https://lore.kernel.org/r/20211010225410.23423-1-cam@neo-zeon.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      023a062f
  6. 07 Oct, 2021 8 commits
  7. 06 Oct, 2021 1 commit
  8. 05 Oct, 2021 2 commits
  9. 04 Oct, 2021 2 commits
  10. 01 Oct, 2021 1 commit
  11. 30 Sep, 2021 4 commits
  12. 28 Sep, 2021 1 commit
    • Thomas Gleixner's avatar
      ALSA: pcsp: Make hrtimer forwarding more robust · f2ff7147
      Thomas Gleixner authored
      The hrtimer callback pcsp_do_timer() prepares rearming of the timer with
      hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to
      forward the expiry time of the hrtimer by a multiple of the period argument
      so that the expiry time greater than the time provided in the 'now'
      argument.
      
      pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry
      time as 'now' argument. That's providing a periodic timer expiry, but is
      not really robust when the timer callback is delayed so that the resulting
      new expiry time is already in the past which causes the callback to be
      invoked immediately again. If the timer is delayed then the back to back
      invocation is not really making it better than skipping the missed
      periods. Sound is distorted in any case.
      
      Use hrtimer_forward_now() which ensures that the next expiry is in the
      future. This prevents hogging the CPU in the timer expiry code and allows
      later on to remove hrtimer_forward() from the public interfaces.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: alsa-devel@alsa-project.org
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f2ff7147
  13. 27 Sep, 2021 2 commits
  14. 23 Sep, 2021 1 commit
  15. 21 Sep, 2021 4 commits
  16. 17 Sep, 2021 1 commit