--- /dev/null
+From cb04fc3b6b076f67d228a0b7d096c69ad486c09c Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 13 Dec 2019 09:51:10 +0100
+Subject: ALSA: hda/ca0132 - Avoid endless loop
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit cb04fc3b6b076f67d228a0b7d096c69ad486c09c upstream.
+
+Introduce a timeout to dspio_clear_response_queue() so that it won't
+be caught in an endless loop even if the hardware doesn't respond
+properly.
+
+Fixes: a73d511c4867 ("ALSA: hda/ca0132: Add unsol handler for DSP and jack detection")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191213085111.22855-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_ca0132.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/sound/pci/hda/patch_ca0132.c
++++ b/sound/pci/hda/patch_ca0132.c
+@@ -1300,13 +1300,14 @@ struct scp_msg {
+
+ static void dspio_clear_response_queue(struct hda_codec *codec)
+ {
++ unsigned long timeout = jiffies + msecs_to_jiffies(1000);
+ unsigned int dummy = 0;
+- int status = -1;
++ int status;
+
+ /* clear all from the response queue */
+ do {
+ status = dspio_read(codec, &dummy);
+- } while (status == 0);
++ } while (status == 0 && time_before(jiffies, timeout));
+ }
+
+ static int dspio_get_response_data(struct hda_codec *codec)
--- /dev/null
+From 377bc0cfabce0244632dada19060839ced4e6949 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 13 Dec 2019 09:51:09 +0100
+Subject: ALSA: hda/ca0132 - Keep power on during processing DSP response
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 377bc0cfabce0244632dada19060839ced4e6949 upstream.
+
+We need to keep power on while processing the DSP response via unsol
+event. Each snd_hda_codec_read() call does the power management, so
+it should work normally, but still it's safer to keep the power up for
+the whole function.
+
+Fixes: a73d511c4867 ("ALSA: hda/ca0132: Add unsol handler for DSP and jack detection")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191213085111.22855-2-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_ca0132.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/sound/pci/hda/patch_ca0132.c
++++ b/sound/pci/hda/patch_ca0132.c
+@@ -4424,12 +4424,14 @@ static void ca0132_process_dsp_response(
+ struct ca0132_spec *spec = codec->spec;
+
+ codec_dbg(codec, "ca0132_process_dsp_response\n");
++ snd_hda_power_up_pm(codec);
+ if (spec->wait_scp) {
+ if (dspio_get_response_data(codec) >= 0)
+ spec->wait_scp = 0;
+ }
+
+ dspio_clear_response_queue(codec);
++ snd_hda_power_down_pm(codec);
+ }
+
+ static void hp_callback(struct hda_codec *codec, struct hda_jack_callback *cb)
--- /dev/null
+From add9d56d7b3781532208afbff5509d7382fb6efe Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 11 Dec 2019 16:57:42 +0100
+Subject: ALSA: pcm: Avoid possible info leaks from PCM stream buffers
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit add9d56d7b3781532208afbff5509d7382fb6efe upstream.
+
+The current PCM code doesn't initialize explicitly the buffers
+allocated for PCM streams, hence it might leak some uninitialized
+kernel data or previous stream contents by mmapping or reading the
+buffer before actually starting the stream.
+
+Since this is a common problem, this patch simply adds the clearance
+of the buffer data at hw_params callback. Although this does only
+zero-clear no matter which format is used, which doesn't mean the
+silence for some formats, but it should be OK because the intention is
+just to clear the previous data on the buffer.
+
+Reported-by: Lionel Koenig <lionel.koenig@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191211155742.3213-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/pcm_native.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/sound/core/pcm_native.c
++++ b/sound/core/pcm_native.c
+@@ -587,6 +587,10 @@ static int snd_pcm_hw_params(struct snd_
+ while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size)
+ runtime->boundary *= 2;
+
++ /* clear the buffer for avoiding possible kernel info leaks */
++ if (runtime->dma_area && !substream->ops->copy_user)
++ memset(runtime->dma_area, 0, runtime->dma_bytes);
++
+ snd_pcm_timer_resolution_change(substream);
+ snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP);
+
--- /dev/null
+From ca1aa2818a53875cfdd175fb5e9a2984e997cce9 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Fri, 6 Dec 2019 09:37:18 -0500
+Subject: btrfs: do not leak reloc root if we fail to read the fs root
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit ca1aa2818a53875cfdd175fb5e9a2984e997cce9 upstream.
+
+If we fail to read the fs root corresponding with a reloc root we'll
+just break out and free the reloc roots. But we remove our current
+reloc_root from this list higher up, which means we'll leak this
+reloc_root. Fix this by adding ourselves back to the reloc_roots list
+so we are properly cleaned up.
+
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/relocation.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -4454,6 +4454,7 @@ int btrfs_recover_relocation(struct btrf
+ reloc_root->root_key.offset);
+ if (IS_ERR(fs_root)) {
+ err = PTR_ERR(fs_root);
++ list_add_tail(&reloc_root->root_list, &reloc_roots);
+ goto out_free;
+ }
+
--- /dev/null
+From 714cd3e8cba6841220dce9063a7388a81de03825 Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Fri, 6 Dec 2019 11:39:00 -0500
+Subject: btrfs: handle ENOENT in btrfs_uuid_tree_iterate
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit 714cd3e8cba6841220dce9063a7388a81de03825 upstream.
+
+If we get an -ENOENT back from btrfs_uuid_iter_rem when iterating the
+uuid tree we'll just continue and do btrfs_next_item(). However we've
+done a btrfs_release_path() at this point and no longer have a valid
+path. So increment the key and go back and do a normal search.
+
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/uuid-tree.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/btrfs/uuid-tree.c
++++ b/fs/btrfs/uuid-tree.c
+@@ -332,6 +332,8 @@ again_search_slot:
+ }
+ if (ret < 0 && ret != -ENOENT)
+ goto out;
++ key.offset++;
++ goto again_search_slot;
+ }
+ item_size -= sizeof(subid_le);
+ offset += sizeof(subid_le);
+btrfs-do-not-leak-reloc-root-if-we-fail-to-read-the-fs-root.patch
+btrfs-handle-enoent-in-btrfs_uuid_tree_iterate.patch
+alsa-pcm-avoid-possible-info-leaks-from-pcm-stream-buffers.patch
+alsa-hda-ca0132-keep-power-on-during-processing-dsp-response.patch
+alsa-hda-ca0132-avoid-endless-loop.patch
drm-mst-fix-query_payload-ack-reply-struct.patch
iio-light-bh1750-resolve-compiler-warning-and-make-c.patch
spi-add-call-to-spi_slave_abort-function-when-spidev.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
