]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.9-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 23 Dec 2019 17:19:32 +0000 (12:19 -0500)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 23 Dec 2019 17:19:32 +0000 (12:19 -0500)
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
btrfs-skip-log-replay-on-orphaned-roots.patch

queue-4.9/alsa-hda-ca0132-avoid-endless-loop.patch [new file with mode: 0644]
queue-4.9/alsa-hda-ca0132-keep-power-on-during-processing-dsp-response.patch [new file with mode: 0644]
queue-4.9/alsa-pcm-avoid-possible-info-leaks-from-pcm-stream-buffers.patch [new file with mode: 0644]
queue-4.9/btrfs-do-not-leak-reloc-root-if-we-fail-to-read-the-fs-root.patch [new file with mode: 0644]
queue-4.9/btrfs-handle-enoent-in-btrfs_uuid_tree_iterate.patch [new file with mode: 0644]
queue-4.9/btrfs-skip-log-replay-on-orphaned-roots.patch [new file with mode: 0644]
queue-4.9/series

diff --git a/queue-4.9/alsa-hda-ca0132-avoid-endless-loop.patch b/queue-4.9/alsa-hda-ca0132-avoid-endless-loop.patch
new file mode 100644 (file)
index 0000000..a9fc1fd
--- /dev/null
@@ -0,0 +1,42 @@
+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)
diff --git a/queue-4.9/alsa-hda-ca0132-keep-power-on-during-processing-dsp-response.patch b/queue-4.9/alsa-hda-ca0132-keep-power-on-during-processing-dsp-response.patch
new file mode 100644 (file)
index 0000000..d4ccb18
--- /dev/null
@@ -0,0 +1,41 @@
+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)
diff --git a/queue-4.9/alsa-pcm-avoid-possible-info-leaks-from-pcm-stream-buffers.patch b/queue-4.9/alsa-pcm-avoid-possible-info-leaks-from-pcm-stream-buffers.patch
new file mode 100644 (file)
index 0000000..bf72d4c
--- /dev/null
@@ -0,0 +1,43 @@
+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);
diff --git a/queue-4.9/btrfs-do-not-leak-reloc-root-if-we-fail-to-read-the-fs-root.patch b/queue-4.9/btrfs-do-not-leak-reloc-root-if-we-fail-to-read-the-fs-root.patch
new file mode 100644 (file)
index 0000000..f100e2a
--- /dev/null
@@ -0,0 +1,37 @@
+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
+@@ -4587,6 +4587,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.9/btrfs-handle-enoent-in-btrfs_uuid_tree_iterate.patch b/queue-4.9/btrfs-handle-enoent-in-btrfs_uuid_tree_iterate.patch
new file mode 100644 (file)
index 0000000..8c3e20b
--- /dev/null
@@ -0,0 +1,37 @@
+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
+@@ -335,6 +335,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.9/btrfs-skip-log-replay-on-orphaned-roots.patch b/queue-4.9/btrfs-skip-log-replay-on-orphaned-roots.patch
new file mode 100644 (file)
index 0000000..4b79229
--- /dev/null
@@ -0,0 +1,78 @@
+From 9bc574de590510eff899c3ca8dbaf013566b5efe Mon Sep 17 00:00:00 2001
+From: Josef Bacik <josef@toxicpanda.com>
+Date: Fri, 6 Dec 2019 09:37:17 -0500
+Subject: btrfs: skip log replay on orphaned roots
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+commit 9bc574de590510eff899c3ca8dbaf013566b5efe upstream.
+
+My fsstress modifications coupled with generic/475 uncovered a failure
+to mount and replay the log if we hit a orphaned root.  We do not want
+to replay the log for an orphan root, but it's completely legitimate to
+have an orphaned root with a log attached.  Fix this by simply skipping
+replaying the log.  We still need to pin it's root node so that we do
+not overwrite it while replaying other logs, as we re-read the log root
+at every stage of the replay.
+
+CC: stable@vger.kernel.org # 4.4+
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/tree-log.c |   23 +++++++++++++++++++++--
+ 1 file changed, 21 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/tree-log.c
++++ b/fs/btrfs/tree-log.c
+@@ -5702,9 +5702,28 @@ again:
+               wc.replay_dest = btrfs_read_fs_root_no_name(fs_info, &tmp_key);
+               if (IS_ERR(wc.replay_dest)) {
+                       ret = PTR_ERR(wc.replay_dest);
++
++                      /*
++                       * We didn't find the subvol, likely because it was
++                       * deleted.  This is ok, simply skip this log and go to
++                       * the next one.
++                       *
++                       * We need to exclude the root because we can't have
++                       * other log replays overwriting this log as we'll read
++                       * it back in a few more times.  This will keep our
++                       * block from being modified, and we'll just bail for
++                       * each subsequent pass.
++                       */
++                      if (ret == -ENOENT)
++                              ret = btrfs_pin_extent_for_log_replay(fs_info,
++                                                      log->node->start,
++                                                      log->node->len);
+                       free_extent_buffer(log->node);
+                       free_extent_buffer(log->commit_root);
+                       kfree(log);
++
++                      if (!ret)
++                              goto next;
+                       btrfs_handle_fs_error(fs_info, ret,
+                               "Couldn't read target root for tree log recovery.");
+                       goto error;
+@@ -5736,7 +5755,6 @@ again:
+                                                 &root->highest_objectid);
+               }
+-              key.offset = found_key.offset - 1;
+               wc.replay_dest->log_root = NULL;
+               free_extent_buffer(log->node);
+               free_extent_buffer(log->commit_root);
+@@ -5744,9 +5762,10 @@ again:
+               if (ret)
+                       goto error;
+-
++next:
+               if (found_key.offset == 0)
+                       break;
++              key.offset = found_key.offset - 1;
+       }
+       btrfs_release_path(path);
index 6fde85a6a898cb0dfdcba0106446866b57852b2b..1960568c3e4f34a6483393ed96367571c19ce3ea 100644 (file)
@@ -1,3 +1,9 @@
+btrfs-skip-log-replay-on-orphaned-roots.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-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
 drm-bridge-analogix-anx78xx-silence-eprobe_defer-war.patch
 iio-light-bh1750-resolve-compiler-warning-and-make-c.patch