1. 14 Aug, 2019 3 commits
    • Hui Peng's avatar
      ALSA: usb-audio: Fix an OOB bug in parse_audio_mixer_unit · daac0715
      Hui Peng authored
      The `uac_mixer_unit_descriptor` shown as below is read from the
      device side. In `parse_audio_mixer_unit`, `baSourceID` field is
      accessed from index 0 to `bNrInPins` - 1, the current implementation
      assumes that descriptor is always valid (the length  of descriptor
      is no shorter than 5 + `bNrInPins`). If a descriptor read from
      the device side is invalid, it may trigger out-of-bound memory
      access.
      
      ```
      struct uac_mixer_unit_descriptor {
      	__u8 bLength;
      	__u8 bDescriptorType;
      	__u8 bDescriptorSubtype;
      	__u8 bUnitID;
      	__u8 bNrInPins;
      	__u8 baSourceID[];
      }
      ```
      
      This patch fixes the bug by add a sanity check on the length of
      the descriptor.
      Reported-by: default avatarHui Peng <benquike@gmail.com>
      Reported-by: default avatarMathias Payer <mathias.payer@nebelwelt.net>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHui Peng <benquike@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      daac0715
    • Hui Wang's avatar
      ALSA: hda - Add a generic reboot_notify · 871b9066
      Hui Wang authored
      Make codec enter D3 before rebooting or poweroff can fix the noise
      issue on some laptops. And in theory it is harmless for all codecs
      to enter D3 before rebooting or poweroff, let us add a generic
      reboot_notify, then realtek and conexant drivers can call this
      function.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      871b9066
    • Hui Wang's avatar
      ALSA: hda - Let all conexant codec enter D3 when rebooting · 401714d9
      Hui Wang authored
      We have 3 new lenovo laptops which have conexant codec 0x14f11f86,
      these 3 laptops also have the noise issue when rebooting, after
      letting the codec enter D3 before rebooting or poweroff, the noise
      disappers.
      
      Instead of adding a new ID again in the reboot_notify(), let us make
      this function apply to all conexant codec. In theory make codec enter
      D3 before rebooting or poweroff is harmless, and I tested this change
      on a couple of other Lenovo laptops which have different conexant
      codecs, there is no side effect so far.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      401714d9
  2. 13 Aug, 2019 1 commit
  3. 10 Aug, 2019 1 commit
    • Wenwen Wang's avatar
      ALSA: hda - Fix a memory leak bug · cfef67f0
      Wenwen Wang authored
      In snd_hda_parse_generic_codec(), 'spec' is allocated through kzalloc().
      Then, the pin widgets in 'codec' are parsed. However, if the parsing
      process fails, 'spec' is not deallocated, leading to a memory leak.
      
      To fix the above issue, free 'spec' before returning the error.
      
      Fixes: 352f7f91 ("ALSA: hda - Merge Realtek parser code to generic parser")
      Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      cfef67f0
  4. 09 Aug, 2019 1 commit
  5. 08 Aug, 2019 2 commits
    • Wenwen Wang's avatar
      ALSA: firewire: fix a memory leak bug · 1be3c1fa
      Wenwen Wang authored
      In iso_packets_buffer_init(), 'b->packets' is allocated through
      kmalloc_array(). Then, the aligned packet size is checked. If it is
      larger than PAGE_SIZE, -EINVAL will be returned to indicate the error.
      However, the allocated 'b->packets' is not deallocated on this path,
      leading to a memory leak.
      
      To fix the above issue, free 'b->packets' before returning the error code.
      
      Fixes: 31ef9134 ("ALSA: add LaCie FireWire Speakers/Griffin FireWave Surround driver")
      Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
      Reviewed-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Cc: <stable@vger.kernel.org> # v2.6.39+
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1be3c1fa
    • Wenwen Wang's avatar
      sound: fix a memory leak bug · c7cd7c74
      Wenwen Wang authored
      In sound_insert_unit(), the controlling structure 's' is allocated through
      kmalloc(). Then it is added to the sound driver list by invoking
      __sound_insert_unit(). Later on, if __register_chrdev() fails, 's' is
      removed from the list through __sound_remove_unit(). If 'index' is not less
      than 0, -EBUSY is returned to indicate the error. However, 's' is not
      deallocated on this execution path, leading to a memory leak bug.
      
      To fix the above issue, free 's' before -EBUSY is returned.
      Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c7cd7c74
  6. 07 Aug, 2019 2 commits
    • Takashi Iwai's avatar
      ALSA: hda - Workaround for crackled sound on AMD controller (1022:1457) · c02f77d3
      Takashi Iwai authored
      A long-time problem on the recent AMD chip (X370, X470, B450, etc with
      PCI ID 1022:1457) with Realtek codecs is the crackled or distorted
      sound for capture streams, as well as occasional playback hiccups.
      After lengthy debugging sessions, the workarounds we've found are like
      the following:
      
      - Set up the proper driver caps for this controller, similar as the
        other AMD controller.
      
      - Correct the DMA position reporting with the fixed FIFO size, which
        is similar like as workaround used for VIA chip set.
      
      - Even after the position correction, PulseAudio still shows
        mysterious stalls of playback streams when a capture is triggered in
        timer-scheduled mode.  Since we have no clear way to eliminate the
        stall, pass the BATCH PCM flag for PA to suppress the tsched mode as
        a temporary workaround.
      
      This patch implements the workarounds.  For the driver caps, it
      defines a new preset, AXZ_DCAPS_PRESET_AMD_SB.  It enables the FIFO-
      corrected position reporting (corresponding to the new position_fix=6)
      and enforces the SNDRV_PCM_INFO_BATCH flag.
      
      Note that the current implementation is merely a workaround.
      Hopefully we'll find a better alternative in future, especially about
      removing the BATCH flag hack again.
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c02f77d3
    • Wenwen Wang's avatar
      ALSA: hiface: fix multiple memory leak bugs · 3d92aa45
      Wenwen Wang authored
      In hiface_pcm_init(), 'rt' is firstly allocated through kzalloc(). Later
      on, hiface_pcm_init_urb() is invoked to initialize 'rt->out_urbs[i]'. In
      hiface_pcm_init_urb(), 'rt->out_urbs[i].buffer' is allocated through
      kzalloc().  However, if hiface_pcm_init_urb() fails, both 'rt' and
      'rt->out_urbs[i].buffer' are not deallocated, leading to memory leak bugs.
      Also, 'rt->out_urbs[i].buffer' is not deallocated if snd_pcm_new() fails.
      
      To fix the above issues, free 'rt' and 'rt->out_urbs[i].buffer'.
      
      Fixes: a91c3fb2 ("Add M2Tech hiFace USB-SPDIF driver")
      Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3d92aa45
  7. 06 Aug, 2019 5 commits
  8. 02 Aug, 2019 2 commits
  9. 31 Jul, 2019 3 commits
  10. 30 Jul, 2019 1 commit
  11. 29 Jul, 2019 1 commit
  12. 27 Jul, 2019 1 commit
    • Samuel Thibault's avatar
      ALSA: hda: Fix 1-minute detection delay when i915 module is not available · 74bf71ed
      Samuel Thibault authored
      Distribution installation images such as Debian include different sets
      of modules which can be downloaded dynamically.  Such images may notably
      include the hda sound modules but not the i915 DRM module, even if the
      latter was enabled at build time, as reported on
      https://bugs.debian.org/931507
      
      In such a case hdac_i915 would be linked in and try to load the i915
      module, fail since it is not there, but still wait for a whole minute
      before giving up binding with it.
      
      This fixes such as case by only waiting for the binding if the module
      was properly loaded (or module support is disabled, in which case i915
      is already compiled-in anyway).
      
      Fixes: f9b54e19 ("ALSA: hda/i915: Allow delayed i915 audio component binding")
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      74bf71ed
  13. 26 Jul, 2019 4 commits
  14. 25 Jul, 2019 1 commit
  15. 24 Jul, 2019 2 commits
  16. 23 Jul, 2019 7 commits
  17. 22 Jul, 2019 3 commits
    • Wenwen Wang's avatar
      ASoC: dapm: fix a memory leak bug · 45004d66
      Wenwen Wang authored
      In snd_soc_dapm_new_control_unlocked(), a kernel buffer is allocated in
      dapm_cnew_widget() to hold the new dapm widget. Then, different actions are
      taken according to the id of the widget, i.e., 'w->id'. If any failure
      occurs during this process, snd_soc_dapm_new_control_unlocked() should be
      terminated by going to the 'request_failed' label. However, the allocated
      kernel buffer is not freed on this code path, leading to a memory leak bug.
      
      To fix the above issue, free the buffer before returning from
      snd_soc_dapm_new_control_unlocked() through the 'request_failed' label.
      Signed-off-by: default avatarWenwen Wang <wenwen@cs.uga.edu>
      Link: https://lore.kernel.org/r/1563803864-2809-1-git-send-email-wang6495@umn.eduSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      45004d66
    • Masahiro Yamada's avatar
      ASoC: SOF: use __u32 instead of uint32_t in uapi headers · 62ec3d13
      Masahiro Yamada authored
      When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to
      make sure they can be included from user-space.
      
      Currently, header.h and fw.h are excluded from the test coverage.
      To make them join the compile-test, we need to fix the build errors
      attached below.
      
      For a case like this, we decided to use __u{8,16,32,64} variable types
      in this discussion:
      
        https://lkml.org/lkml/2019/6/5/18
      
      Build log:
      
        CC      usr/include/sound/sof/header.h.s
        CC      usr/include/sound/sof/fw.h.s
      In file included from <command-line>:32:0:
      ./usr/include/sound/sof/header.h:19:2: error: unknown type name ‘uint32_t’
        uint32_t magic;  /**< 'S', 'O', 'F', '\0' */
        ^~~~~~~~
      ./usr/include/sound/sof/header.h:20:2: error: unknown type name ‘uint32_t’
        uint32_t type;  /**< component specific type */
        ^~~~~~~~
      ./usr/include/sound/sof/header.h:21:2: error: unknown type name ‘uint32_t’
        uint32_t size;  /**< size in bytes of data excl. this struct */
        ^~~~~~~~
      ./usr/include/sound/sof/header.h:22:2: error: unknown type name ‘uint32_t’
        uint32_t abi;  /**< SOF ABI version */
        ^~~~~~~~
      ./usr/include/sound/sof/header.h:23:2: error: unknown type name ‘uint32_t’
        uint32_t reserved[4]; /**< reserved for future use */
        ^~~~~~~~
      ./usr/include/sound/sof/header.h:24:2: error: unknown type name ‘uint32_t’
        uint32_t data[0]; /**< Component data - opaque to core */
        ^~~~~~~~
      In file included from <command-line>:32:0:
      ./usr/include/sound/sof/fw.h:49:2: error: unknown type name ‘uint32_t’
        uint32_t size;  /* bytes minus this header */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:50:2: error: unknown type name ‘uint32_t’
        uint32_t offset; /* offset from base */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:64:2: error: unknown type name ‘uint32_t’
        uint32_t size;  /* bytes minus this header */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:65:2: error: unknown type name ‘uint32_t’
        uint32_t num_blocks; /* number of blocks */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:73:2: error: unknown type name ‘uint32_t’
        uint32_t file_size; /* size of file minus this header */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:74:2: error: unknown type name ‘uint32_t’
        uint32_t num_modules; /* number of modules */
        ^~~~~~~~
      ./usr/include/sound/sof/fw.h:75:2: error: unknown type name ‘uint32_t’
        uint32_t abi;  /* version of header format */
        ^~~~~~~~
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Link: https://lore.kernel.org/r/20190721142308.30306-1-yamada.masahiro@socionext.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      62ec3d13
    • Enric Balletbo i Serra's avatar
      SoC: rockchip: rockchip_max98090: Enable MICBIAS for headset keypress detection · f86621cd
      Enric Balletbo i Serra authored
      The TS3A227E says that the headset keypress detection needs the MICBIAS
      power in order to report the key events to ensure proper operation
      The headset keypress detection needs the MICBIAS power in order to report
      the key events all the time as long as MIC is present. So MICBIAS pin
      is forced on when a MICROPHONE is detected.
      
      On Veyron Minnie I observed that if the MICBIAS power is not present and
      the key press detection is activated (just because it is enabled when you
      insert a headset), it randomly reports a keypress on insert.
      E.g. (KEY_PLAYPAUSE)
      
       Event: (SW_HEADPHONE_INSERT), value 1
       Event: (SW_MICROPHONE_INSERT), value 1
       Event: -------------- SYN_REPORT ------------
       Event: (KEY_PLAYPAUSE), value 1
      
      Userspace thinks that KEY_PLAYPAUSE is pressed and produces the annoying
      effect that the media player starts a play/pause loop.
      
      Note that, although most of the time the key reported is the one
      associated with BTN_0, not always this is true. On my tests I also saw
      different keys reported
      Signed-off-by: default avatarEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Link: https://lore.kernel.org/r/20190719173929.24065-1-enric.balletbo@collabora.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      f86621cd