From c9e6909b14895426865efdc5543f56656b8d6792 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 23 Dec 2019 12:19:06 -0500 Subject: [PATCH] 4.4-stable patches added patches: alsa-hda-ca0132-avoid-endless-loop.patch alsa-hda-ca0132-keep-power-on-during-processing-dsp-response.patch alsa-pcm-avoid-possible-info-leaks-from-pcm-stream-buffers.patch 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-hda-ca0132-avoid-endless-loop.patch | 42 ++++++++++++++++++ ...er-on-during-processing-dsp-response.patch | 41 ++++++++++++++++++ ...e-info-leaks-from-pcm-stream-buffers.patch | 43 +++++++++++++++++++ ...-root-if-we-fail-to-read-the-fs-root.patch | 37 ++++++++++++++++ ...le-enoent-in-btrfs_uuid_tree_iterate.patch | 37 ++++++++++++++++ queue-4.4/series | 5 +++ 6 files changed, 205 insertions(+) create mode 100644 queue-4.4/alsa-hda-ca0132-avoid-endless-loop.patch create mode 100644 queue-4.4/alsa-hda-ca0132-keep-power-on-during-processing-dsp-response.patch create mode 100644 queue-4.4/alsa-pcm-avoid-possible-info-leaks-from-pcm-stream-buffers.patch create mode 100644 queue-4.4/btrfs-do-not-leak-reloc-root-if-we-fail-to-read-the-fs-root.patch create mode 100644 queue-4.4/btrfs-handle-enoent-in-btrfs_uuid_tree_iterate.patch diff --git a/queue-4.4/alsa-hda-ca0132-avoid-endless-loop.patch b/queue-4.4/alsa-hda-ca0132-avoid-endless-loop.patch new file mode 100644 index 00000000000..a9fc1fd3632 --- /dev/null +++ b/queue-4.4/alsa-hda-ca0132-avoid-endless-loop.patch @@ -0,0 +1,42 @@ +From cb04fc3b6b076f67d228a0b7d096c69ad486c09c Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 13 Dec 2019 09:51:10 +0100 +Subject: ALSA: hda/ca0132 - Avoid endless loop + +From: Takashi Iwai + +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: +Link: https://lore.kernel.org/r/20191213085111.22855-3-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.4/alsa-hda-ca0132-keep-power-on-during-processing-dsp-response.patch b/queue-4.4/alsa-hda-ca0132-keep-power-on-during-processing-dsp-response.patch new file mode 100644 index 00000000000..d4ccb181992 --- /dev/null +++ b/queue-4.4/alsa-hda-ca0132-keep-power-on-during-processing-dsp-response.patch @@ -0,0 +1,41 @@ +From 377bc0cfabce0244632dada19060839ced4e6949 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 13 Dec 2019 09:51:09 +0100 +Subject: ALSA: hda/ca0132 - Keep power on during processing DSP response + +From: Takashi Iwai + +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: +Link: https://lore.kernel.org/r/20191213085111.22855-2-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.4/alsa-pcm-avoid-possible-info-leaks-from-pcm-stream-buffers.patch b/queue-4.4/alsa-pcm-avoid-possible-info-leaks-from-pcm-stream-buffers.patch new file mode 100644 index 00000000000..bf72d4c149d --- /dev/null +++ b/queue-4.4/alsa-pcm-avoid-possible-info-leaks-from-pcm-stream-buffers.patch @@ -0,0 +1,43 @@ +From add9d56d7b3781532208afbff5509d7382fb6efe Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Wed, 11 Dec 2019 16:57:42 +0100 +Subject: ALSA: pcm: Avoid possible info leaks from PCM stream buffers + +From: Takashi Iwai + +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 +Cc: +Link: https://lore.kernel.org/r/20191211155742.3213-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-4.4/btrfs-do-not-leak-reloc-root-if-we-fail-to-read-the-fs-root.patch b/queue-4.4/btrfs-do-not-leak-reloc-root-if-we-fail-to-read-the-fs-root.patch new file mode 100644 index 00000000000..a4b7063ba3e --- /dev/null +++ b/queue-4.4/btrfs-do-not-leak-reloc-root-if-we-fail-to-read-the-fs-root.patch @@ -0,0 +1,37 @@ +From ca1aa2818a53875cfdd175fb5e9a2984e997cce9 Mon Sep 17 00:00:00 2001 +From: Josef Bacik +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 + +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 +Reviewed-by: Johannes Thumshirn +Signed-off-by: Josef Bacik +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-4.4/btrfs-handle-enoent-in-btrfs_uuid_tree_iterate.patch b/queue-4.4/btrfs-handle-enoent-in-btrfs_uuid_tree_iterate.patch new file mode 100644 index 00000000000..7522c256e1e --- /dev/null +++ b/queue-4.4/btrfs-handle-enoent-in-btrfs_uuid_tree_iterate.patch @@ -0,0 +1,37 @@ +From 714cd3e8cba6841220dce9063a7388a81de03825 Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Fri, 6 Dec 2019 11:39:00 -0500 +Subject: btrfs: handle ENOENT in btrfs_uuid_tree_iterate + +From: Josef Bacik + +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 +Reviewed-by: Johannes Thumshirn +Signed-off-by: Josef Bacik +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/series b/queue-4.4/series index ce8027dc090..6e6f95e2dc3 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -1,3 +1,8 @@ +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 -- 2.47.3