--- /dev/null
+From 333f31436d3db19f4286f8862a00ea1d8d8420a1 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 29 Aug 2019 09:52:02 +0200
+Subject: ALSA: hda - Fix potential endless loop at applying quirks
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 333f31436d3db19f4286f8862a00ea1d8d8420a1 upstream.
+
+Since the chained quirks via chained_before flag is applied before the
+depth check, it may lead to the endless recursive calls, when the
+chain were set up incorrectly. Fix it by moving the depth check at
+the beginning of the loop.
+
+Fixes: 1f57825077dc ("ALSA: hda - Add chained_before flag to the fixup entry")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/hda_auto_parser.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/pci/hda/hda_auto_parser.c
++++ b/sound/pci/hda/hda_auto_parser.c
+@@ -827,6 +827,8 @@ static void apply_fixup(struct hda_codec
+ while (id >= 0) {
+ const struct hda_fixup *fix = codec->fixup_list + id;
+
++ if (++depth > 10)
++ break;
+ if (fix->chained_before)
+ apply_fixup(codec, fix->chain_id, action, depth + 1);
+
+@@ -866,8 +868,6 @@ static void apply_fixup(struct hda_codec
+ }
+ if (!fix->chained || fix->chained_before)
+ break;
+- if (++depth > 10)
+- break;
+ id = fix->chain_id;
+ }
+ }
--- /dev/null
+From 89781d0806c2c4f29072d3f00cb2dd4274aabc3d Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 30 Aug 2019 12:03:38 +0200
+Subject: ALSA: hda/realtek - Fix overridden device-specific initialization
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 89781d0806c2c4f29072d3f00cb2dd4274aabc3d upstream.
+
+The recent change to shuffle the codec initialization procedure for
+Realtek via commit 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on
+later") caused the silent output on some machines. This change was
+supposed to be safe, but it isn't actually; some devices have quirk
+setups to override the EAPD via COEF or BTL in the additional verb
+table, which is applied at the beginning of snd_hda_gen_init(). And
+this EAPD setup is again overridden in alc_auto_init_amp().
+
+For recovering from the regression, tell snd_hda_gen_init() not to
+apply the verbs there by a new flag, then apply the verbs in
+alc_init().
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204727
+Fixes: 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on later")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/hda_generic.c | 3 ++-
+ sound/pci/hda/hda_generic.h | 1 +
+ sound/pci/hda/patch_realtek.c | 2 ++
+ 3 files changed, 5 insertions(+), 1 deletion(-)
+
+--- a/sound/pci/hda/hda_generic.c
++++ b/sound/pci/hda/hda_generic.c
+@@ -5807,7 +5807,8 @@ int snd_hda_gen_init(struct hda_codec *c
+ if (spec->init_hook)
+ spec->init_hook(codec);
+
+- snd_hda_apply_verbs(codec);
++ if (!spec->skip_verbs)
++ snd_hda_apply_verbs(codec);
+
+ init_multi_out(codec);
+ init_extra_out(codec);
+--- a/sound/pci/hda/hda_generic.h
++++ b/sound/pci/hda/hda_generic.h
+@@ -236,6 +236,7 @@ struct hda_gen_spec {
+ unsigned int indep_hp_enabled:1; /* independent HP enabled */
+ unsigned int have_aamix_ctl:1;
+ unsigned int hp_mic_jack_modes:1;
++ unsigned int skip_verbs:1; /* don't apply verbs at snd_hda_gen_init() */
+
+ /* additional mute flags (only effective with auto_mute_via_amp=1) */
+ u64 mute_bits;
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -773,9 +773,11 @@ static int alc_init(struct hda_codec *co
+ if (spec->init_hook)
+ spec->init_hook(codec);
+
++ spec->gen.skip_verbs = 1; /* applied in below */
+ snd_hda_gen_init(codec);
+ alc_fix_pll(codec);
+ alc_auto_init_amp(codec, spec->init_amp);
++ snd_hda_apply_verbs(codec); /* apply verbs here after own init */
+
+ snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_INIT);
+
--- /dev/null
+From 08b0c891605acf727e43e3e03a25857d3e789b61 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Thu, 15 Aug 2019 11:30:50 +0300
+Subject: drm/vmwgfx: Fix double free in vmw_recv_msg()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 08b0c891605acf727e43e3e03a25857d3e789b61 upstream.
+
+We recently added a kfree() after the end of the loop:
+
+ if (retries == RETRIES) {
+ kfree(reply);
+ return -EINVAL;
+ }
+
+There are two problems. First the test is wrong and because retries
+equals RETRIES if we succeed on the last iteration through the loop.
+Second if we fail on the last iteration through the loop then the kfree
+is a double free.
+
+When you're reading this code, please note the break statement at the
+end of the while loop. This patch changes the loop so that if it's not
+successful then "reply" is NULL and we can test for that afterward.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 6b7c3b86f0b6 ("drm/vmwgfx: fix memory leak when too many retries have occurred")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+@@ -264,7 +264,7 @@ static int vmw_recv_msg(struct rpc_chann
+
+ if ((HIGH_WORD(ebx) & MESSAGE_STATUS_SUCCESS) == 0) {
+ kfree(reply);
+-
++ reply = NULL;
+ if ((HIGH_WORD(ebx) & MESSAGE_STATUS_CPT) != 0) {
+ /* A checkpoint occurred. Retry. */
+ continue;
+@@ -288,7 +288,7 @@ static int vmw_recv_msg(struct rpc_chann
+
+ if ((HIGH_WORD(ecx) & MESSAGE_STATUS_SUCCESS) == 0) {
+ kfree(reply);
+-
++ reply = NULL;
+ if ((HIGH_WORD(ecx) & MESSAGE_STATUS_CPT) != 0) {
+ /* A checkpoint occurred. Retry. */
+ continue;
+@@ -300,10 +300,8 @@ static int vmw_recv_msg(struct rpc_chann
+ break;
+ }
+
+- if (retries == RETRIES) {
+- kfree(reply);
++ if (!reply)
+ return -EINVAL;
+- }
+
+ *msg_len = reply_len;
+ *msg = reply;
--- /dev/null
+From 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 Mon Sep 17 00:00:00 2001
+From: Gustavo Romero <gromero@linux.ibm.com>
+Date: Wed, 4 Sep 2019 00:55:27 -0400
+Subject: powerpc/tm: Fix FP/VMX unavailable exceptions inside a transaction
+
+From: Gustavo Romero <gromero@linux.ibm.com>
+
+commit 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 upstream.
+
+When we take an FP unavailable exception in a transaction we have to
+account for the hardware FP TM checkpointed registers being
+incorrect. In this case for this process we know the current and
+checkpointed FP registers must be the same (since FP wasn't used
+inside the transaction) hence in the thread_struct we copy the current
+FP registers to the checkpointed ones.
+
+This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr
+to determine if FP was on when in userspace. thread->ckpt_regs.msr
+represents the state of the MSR when exiting userspace. This is setup
+by check_if_tm_restore_required().
+
+Unfortunatley there is an optimisation in giveup_all() which returns
+early if tsk->thread.regs->msr (via local variable `usermsr`) has
+FP=VEC=VSX=SPE=0. This optimisation means that
+check_if_tm_restore_required() is not called and hence
+thread->ckpt_regs.msr is not updated and will contain an old value.
+
+This can happen if due to load_fp=255 we start a userspace process
+with MSR FP=1 and then we are context switched out. In this case
+thread->ckpt_regs.msr will contain FP=1. If that same process is then
+context switched in and load_fp overflows, MSR will have FP=0. If that
+process now enters a transaction and does an FP instruction, the FP
+unavailable will not update thread->ckpt_regs.msr (the bug) and MSR
+FP=1 will be retained in thread->ckpt_regs.msr. tm_reclaim_thread()
+will then not perform the required memcpy and the checkpointed FP regs
+in the thread struct will contain the wrong values.
+
+The code path for this happening is:
+
+ Userspace: Kernel
+ Start userspace
+ with MSR FP/VEC/VSX/SPE=0 TM=1
+ < -----
+ ...
+ tbegin
+ bne
+ fp instruction
+ FP unavailable
+ ---- >
+ fp_unavailable_tm()
+ tm_reclaim_current()
+ tm_reclaim_thread()
+ giveup_all()
+ return early since FP/VMX/VSX=0
+ /* ckpt MSR not updated (Incorrect) */
+ tm_reclaim()
+ /* thread_struct ckpt FP regs contain junk (OK) */
+ /* Sees ckpt MSR FP=1 (Incorrect) */
+ no memcpy() performed
+ /* thread_struct ckpt FP regs not fixed (Incorrect) */
+ tm_recheckpoint()
+ /* Put junk in hardware checkpoint FP regs */
+ ....
+ < -----
+ Return to userspace
+ with MSR TM=1 FP=1
+ with junk in the FP TM checkpoint
+ TM rollback
+ reads FP junk
+
+This is a data integrity problem for the current process as the FP
+registers are corrupted. It's also a security problem as the FP
+registers from one process may be leaked to another.
+
+This patch moves up check_if_tm_restore_required() in giveup_all() to
+ensure thread->ckpt_regs.msr is updated correctly.
+
+A simple testcase to replicate this will be posted to
+tools/testing/selftests/powerpc/tm/tm-poison.c
+
+Similarly for VMX.
+
+This fixes CVE-2019-15030.
+
+Fixes: f48e91e87e67 ("powerpc/tm: Fix FP and VMX register corruption")
+Cc: stable@vger.kernel.org # 4.12+
+Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com>
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190904045529.23002-1-gromero@linux.vnet.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/process.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/kernel/process.c
++++ b/arch/powerpc/kernel/process.c
+@@ -476,13 +476,14 @@ void giveup_all(struct task_struct *tsk)
+ if (!tsk->thread.regs)
+ return;
+
++ check_if_tm_restore_required(tsk);
++
+ usermsr = tsk->thread.regs->msr;
+
+ if ((usermsr & msr_all_available) == 0)
+ return;
+
+ msr_check_and_set(msr_all_available);
+- check_if_tm_restore_required(tsk);
+
+ #ifdef CONFIG_PPC_FPU
+ if (usermsr & MSR_FP)
--- /dev/null
+From 5e2d2cc2588bd3307ce3937acbc2ed03c830a861 Mon Sep 17 00:00:00 2001
+From: Liangyan <liangyan.peng@linux.alibaba.com>
+Date: Mon, 26 Aug 2019 20:16:33 +0800
+Subject: sched/fair: Don't assign runtime for throttled cfs_rq
+
+From: Liangyan <liangyan.peng@linux.alibaba.com>
+
+commit 5e2d2cc2588bd3307ce3937acbc2ed03c830a861 upstream.
+
+do_sched_cfs_period_timer() will refill cfs_b runtime and call
+distribute_cfs_runtime to unthrottle cfs_rq, sometimes cfs_b->runtime
+will allocate all quota to one cfs_rq incorrectly, then other cfs_rqs
+attached to this cfs_b can't get runtime and will be throttled.
+
+We find that one throttled cfs_rq has non-negative
+cfs_rq->runtime_remaining and cause an unexpetced cast from s64 to u64
+in snippet:
+
+ distribute_cfs_runtime() {
+ runtime = -cfs_rq->runtime_remaining + 1;
+ }
+
+The runtime here will change to a large number and consume all
+cfs_b->runtime in this cfs_b period.
+
+According to Ben Segall, the throttled cfs_rq can have
+account_cfs_rq_runtime called on it because it is throttled before
+idle_balance, and the idle_balance calls update_rq_clock to add time
+that is accounted to the task.
+
+This commit prevents cfs_rq to be assgined new runtime if it has been
+throttled until that distribute_cfs_runtime is called.
+
+Signed-off-by: Liangyan <liangyan.peng@linux.alibaba.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
+Reviewed-by: Ben Segall <bsegall@google.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: shanpeic@linux.alibaba.com
+Cc: stable@vger.kernel.org
+Cc: xlpang@linux.alibaba.com
+Fixes: d3d9dc330236 ("sched: Throttle entities exceeding their allowed bandwidth")
+Link: https://lkml.kernel.org/r/20190826121633.6538-1-liangyan.peng@linux.alibaba.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/sched/fair.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/kernel/sched/fair.c
++++ b/kernel/sched/fair.c
+@@ -3882,6 +3882,8 @@ static void __account_cfs_rq_runtime(str
+ if (likely(cfs_rq->runtime_remaining > 0))
+ return;
+
++ if (cfs_rq->throttled)
++ return;
+ /*
+ * if we're unable to extend our runtime we resched so that the active
+ * hierarchy can be throttled
+@@ -4077,6 +4079,9 @@ static u64 distribute_cfs_runtime(struct
+ if (!cfs_rq_throttled(cfs_rq))
+ goto next;
+
++ /* By the above check, this should never be true */
++ SCHED_WARN_ON(cfs_rq->runtime_remaining > 0);
++
+ runtime = -cfs_rq->runtime_remaining + 1;
+ if (runtime > remaining)
+ runtime = remaining;
projects / thirdparty / kernel / stable-queue.git / commitdiff
